 |
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
| Datasheet File OCR Text: |
| mcf5249um/d rev. 1.0, 10/2002 mcf5249 coldfire ? integrated microprocessor user?s manual
table of contents paragraph title page number number motorola table of contents toc-1 section 1 mcf5249 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1 1.1 mcf5249 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1 1.2 mcf5249 feature introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1 1.3 mcf5249 block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2 1.4 mcf5249 feature details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3 1.5 160 mapbga ball assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5 1.6 mcf5249 functional overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6 1.6.1 coldfire v2 core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6 1.6.2 dma controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6 1.6.3 enhanced multiply and accumulate module (emac) . . . . . . . . . . . . . . . . . . . . . . .1-6 1.6.4 instruction cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6 1.6.5 internal 96-kbyte sram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6 1.6.6 dram controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7 1.6.7 system interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7 1.6.8 external bus interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7 1.6.9 serial audio interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7 1.6.10 iec958 digital audio interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7 1.6.11 audio bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7 1.6.12 cd-rom encoder/decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-8 1.6.13 dual uart module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-8 1.6.14 queued serial peripheral interface qspi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-8 1.6.15 timer module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-8 1.6.16 ide and smartmedia interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9 1.6.17 analog/digital converter (adc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9 1.6.18 flash memory card interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9 1.6.19 i2c module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9 1.6.20 chip-selects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9 1.6.21 gpio interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9 1.6.22 interrupt controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9 1.6.23 jtag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-10 1.6.24 system debug interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-10 1.6.25 crystal and on-chip pll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-10 section 2 signal description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1 2.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1 2.2 gpio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4 2.3 mcf5249 bus signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4 2.3.1 address bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4 2.3.2 read-write control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4 2.3.3 output enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5 2.3.1 data bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5 2.3.5 transfer acknowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5 2.4 sdram controller signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5 2.5 chip selects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5 2.6 isa bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6 2.7 bus buffer signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6 2.8 i2c module signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6 2.9 serial module signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6 2.10 timer module signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7 2.11 serial audio interface signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7 2.12 digital audio interface signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9 toc--2 mcf5249um motorola table of contents paragraph title page number number 2.13 subcode interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9 2.14 analog to digital converter (adc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9 2.15 secure digital/ memorystick card interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-10 2.16 queued serial peripheral interface (qspi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-10 2.17 crystal trim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11 2.18 clock out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11 2.19 debug and test signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11 2.19.1 test mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11 2.19.2 high impedance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11 2.19.3 processor clock output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11 2.19.4 debug data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11 2.19.5 processor status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11 2.20 bdm/jtag signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-12 2.20.1 test clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-12 2.20.2 test reset/development serial clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-12 2.20.3 test mode select/break point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13 2.20.4 test data input/development serial input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13 2.20.5 test data output/development serial output . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13 2.21 clock and reset signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14 2.21.1 reset in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14 2.21.2 system bus input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14 section 3 coldfire core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1 3.1 processor pipelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1 3.2 processor register description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2 3.2.1 user programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2 3.2.1.1 data registers (d0?d7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2 3.2.1.2 address registers (a0?a6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2 3.2.1.3 stack pointer (a7,sp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2 3.2.1.4 program counter (pc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3 3.2.1.5 condition code register (ccr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3 3.2.2 enhanced multiply accumulate module (emac) user programming model . . . . . .3-4 3.2.2.1 e mac instruction set summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4 3.2.3 supervisor programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5 3.2.3.1 status register (sr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 6 3.2.3.2 vector base register (vbr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6 3.3 exception processing overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7 3.4 exception stack frame definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8 3.5 processor exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10 3.5.1 access error exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10 3.5.2 address error exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10 3.5.3 illegal instruction exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10 3.5.4 divide by zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10 3.5.5 privilege violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11 3.5.6 trace exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11 3.5.7 debug interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11 3.5.8 rte and format error exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11 3.5.9 trap instruction exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12 3.5.10 interrupt exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12 3.5.11 fault-on-fault halt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12 3.5.12 reset exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12 table of contents paragraph title page number number motorola table of contents toc-3 3.6 instruction execution timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12 3.6.1 timing assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13 3.6.2 move instruction execution times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13 3.7 standard one operand instruction execution times . . . . . . . . . . . . . . . . . . . . . . .3-15 3.8 standard two operand instruction execution times . . . . . . . . . . . . . . . . . . . . . . .3-16 3.9 miscellaneous instruction execution times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18 3.10 branch instruction execution times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19 section 4 phase-locked loop and clock dividers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1 4.1 pll features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1 4.2 pll programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2 4.2.1 pll operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 4.2.2 pll lock-in time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 4.2.3 pll electrical limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 4.3 audio clock generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5 4.4 reduced power mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6 4.5 recommended settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6 section 5 instruction cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1 5.1 instruction cache features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1 5.2 instruction cache physical organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1 5.3 instruction cache operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2 5.3.1 interaction with other modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2 5.3.2 memory reference attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3 5.3.3 cache coherency and invalidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3 5.3.4 reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3 5.3.5 cache miss fetch algorithm/line fills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3 5.4 instruction cache programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5 5.4.1 instruction cache registers memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5 5.4.2 instruction cache register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6 5.4.2.1 cache control register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6 5.4.2.2 access control registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8 section 6 static ram (sram) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1 6.1 sram features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1 6.2 sram operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1 6.3 sram programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1 6.3.1 sram base address register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1 6.3.2 sram initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4 6.3.3 sram initialization code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4 6.3.4 power management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4 section 7 synchronous dram controller module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1 7.1 dram features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1 7.1.1 definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1 7.1.2 block diagram and major components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1 7.2 dram controller operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2 7.1.2 dram controller registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2 7.3 synchronous operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 7.3.1 dram controller signals in synchronous mode . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4 7.3.2 synchronous register set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5 7.3.2.1 dram control register (dcr) (synchronous mode) . . . . . . . . . . . . . . . . . . . . . . .7-5 7.3.2.2 dram address and control (dacr0/dacr1) (synchronous mode) . . . . . . . . . . .7-7 toc--4 mcf5249um motorola table of contents paragraph title page number number 7.3.2.3 dram controller mask registers (dmr0/dmr1) . . . . . . . . . . . . . . . . . . . . . . . . . .7-9 7.3.3 general synchronous operation guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10 7.3.3.1 address multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10 7.3.3.2 interfacing example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12 7.3.3.3 burst page mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12 7.3.3.4 continuous page mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-14 7.3.3.5 auto-refresh operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-16 7.3.3.6 self-refresh operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-17 7.3.4 initialization sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-18 7.3.4.1 mode register settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-18 7.4 sdram example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-19 7.4.1 sdram interface configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-19 7.4.2 dcr initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-20 7.4.3 dacr initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-20 7.4.4 dmr initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-22 7.4.5 mode register initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-23 7.4.6 initialization code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-24 section 8 bus operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 8.1 bus features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 8.2 bus and control signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 8.2.1 address bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 8.2.2 read/write control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2 8.2.3 transfer acknowledge (ta) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2 8.2.4 data bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2 8.2.5 chip selects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3 8.2.6 output enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3 8.3 clock and reset signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3 8.3.1 reset in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 8.3.2 system bus clock output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 8.4 bus characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 8.5 data transfer operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 8.5.1 bus cycle execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6 8.5.2 read cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-7 8.5.3 write cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8 8.5.4 back-to-back bus cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10 8.5.5 burst cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11 8.5.5.1 line transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11 8.5.5.2 line read bus cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11 8.5.5.3 line write bus cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12 8.6 misaligned operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14 8.7 reset operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15 8.7.1 software watchdog reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16 section 9 system integration module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1 9.1 sim introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1 9.1.1 sim features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1 9.2 programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1 9.2.1 sim register memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1 9.3 sim programming and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3 9.3.1 module base address registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3 9.3.2 device id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5 table of contents paragraph title page number number motorola table of contents toc-5 9.3.3 interrupt controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6 9.4 interrupt interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6 9.4.1 primary controller interrupt registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6 9.4.1.1 interrupt mask register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9 9.4.1.2 interrupt pending register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10 9.4.2 secondary interrupt controller registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-11 9.4.2.1 interrupt level selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-11 9.4.2.2 interrupt vector generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12 9.4.2.3 spurious vector register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12 9.4.2.4 secondary interrupt sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12 9.4.3 software interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15 9.5 system protection and reset status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15 9.5.1 reset status register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15 9.5.2 software watchdog timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-16 9.5.2.1 system protection control register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-18 9.5.2.2 software watchdog interrupt vector register . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-19 9.5.2.3 software watchdog service register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-20 9.6 cpu stop instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-20 9.7 mcf5249 bus arbitration control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-20 9.7.1 default bus master park register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-20 9.7.1.1 internal arbitration operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-20 9.7.1.2 park register bit configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-21 9.8 general purpose i/os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-23 9.8.1 general purpose inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-23 9.8.1.1 general purpose input interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-25 9.8.2 general purpose outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-26 section 10 chip-select module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1 10.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1 10.1.1 chip select features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1 10.2 chip-select signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1 10.2.1 chip selects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1 10.2.1.1 cs0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1 10.2.1.2 cs1/gpio1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1 10.2.1.3 cs2/ide-dior/gpio13 and ide-diow/gpio14 . . . . . . . . . . . . . . . . . . . . . . . . .10-1 10.2.1.4 cs3/sre/gpio11 and swe/gpio12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2 10.2.2 output enable oe/gpio9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2 10.2.3 buffer enable signals - bufenb1 and bufenb2 . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2 10.2.4 iordy - bus termination signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2 10.3 mcf5249chip-select operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2 10.3.1 chip-select module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2 10.3.1.1 general chip select operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3 10.3.1.1.1 port sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4 10.3.2 global chip-select operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4 10.4 programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4 10.4.1 chip-select registers memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4 10.4.2 chip select module registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6 10.4.2.1 chip select address register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6 10.4.2.2 chip select mask register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6 10.4.2.3 chip select control register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-8 10.4.2.4 code example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-10 toc--6 mcf5249um motorola table of contents paragraph title page number number section 11 timer module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1 11.1 timer module overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1 11.2 timer features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1 11.3 timer signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1 11.3.1 timer inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1 11.3.2 timer outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1 11.4 general-purpose timer units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2 11.4.1 selecting the prescaler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3 11.4.2 capture mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3 11.4.3 configuring the timer for reference compare . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3 11.4.4 configuring the timer for output mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3 11.5 general-purpose timer registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3 11.5.1 timer mode registers (tmr0, tmr1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4 11.5.2 timer reference registers (trr0, trr1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-5 11.5.3 timer capture registers (tcr0, tcr1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-5 11.5.4 timer counters (tcn0, tcn1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6 11.5.5 timer event registers (ter0, ter1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6 11.5.6 timer initialization example code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7 11.5.6.1 timer 0 (timer mode register) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7 11.5.6.2 timer 0 (timer reference register 0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-8 11.5.6.3 timer 1 (timer mode register 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-8 section 12 analog to digital converter (adc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-1 12.1 adc overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-1 12.2 adc functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2 section 13 ide and flashmedia interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-1 13.1 ide and smartmedia overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-1 13.1.1 buffer enables bufenb1, bufenb2, and associated logic . . . . . . . . . . . . . . . . . . . .13-2 13.1.2 generation of ide-dior, ide-diow, sre, swe . . . . . . . . . . . . . . . . . . . . . . . . .13-4 13.1.3 cycle termination on cs2, cs3 (dior, diow, sre, swe) . . . . . . . . . . . . . . . .13-5 13.2 smartmedia interface setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-6 13.2.1 smartmedia timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-7 13.3 setting up the ide interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-8 13.3.1 ide timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-8 13.4 flashmedia interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-10 13.4.1 flashmedia interface registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-10 13.4.1.1 flashmedia clock generation and configuration . . . . . . . . . . . . . . . . . . . . . . . .13-11 13.4.2 flashmedia interface operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-12 13.4.2.1 flashmedia command registers in memorystick mode . . . . . . . . . . . . . . . . . . .13-13 13.4.2.2 flashmedia command register 1 in secure digital mode . . . . . . . . . . . . . . . . .13-13 13.4.2.3 flashmedia command register 2 in secure digital mode . . . . . . . . . . . . . . . . .13-14 13.4.3 flashmedia data register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-15 13.4.3.1 flashmedia status register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-15 13.4.4 flashmedia interrupt interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-15 13.4.5 flashmedia interface operation in memorystick mode . . . . . . . . . . . . . . . . . . . .13-16 13.4.5.1 reading data from the memorystick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-17 13.4.5.2 writing data to the memorystick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-18 13.4.5.3 interrupt from memorystick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-19 13.4.6 flashmedia interface operation in secure digital (sd) mode . . . . . . . . . . . . . . .13-20 13.4.6.1 sent command to card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-20 13.4.6.2 write data to card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-21 table of contents paragraph title page number number motorola table of contents toc-7 13.4.7 commonly used commands in sd mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-23 13.4.7.1 send command to card (no data) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-23 13.4.7.2 send command to card (receive multiple data blocks and status) . . . . . . . . .13-24 13.4.7.3 send command to card (write multiple data blocks) . . . . . . . . . . . . . . . . . . . .13-25 section 14 dma controller module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-1 14.1 dma features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-2 14.2 dma signal description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-2 14.2.1 dma request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-2 14.3 dma module overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-2 14.4 dma programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-3 14.4.1 request source selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5 14.4.2 source address register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-8 14.4.3 flashmedia data registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-9 14.4.4 byte count register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-9 14.4.5 dma control register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-10 14.4.6 dma status register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-13 14.4.7 dma interrupt vector register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-15 14.5 transfer request generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-15 14.5.1 cycle-steal mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-15 14.5.2 continuous mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-15 14.6 data transfer modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-16 14.6.1 dual-address transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-16 14.6.1.1 dual-address read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-16 14.6.1.2 dual-address write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-16 14.7 dma transfer functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-16 14.7.1 channel initialization and startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-17 14.7.1.1 channel prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-17 14.7.1.2 programming the dma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-17 14.7.2 data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-18 14.7.2.1 periphery request operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-18 14.7.2.2 auto alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-18 14.7.2.3 bandwidth control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-19 14.7.3 channel termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-19 14.7.3.1 error conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-19 14.7.3.2 interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-19 section 15 uart modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-1 15.1 module overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-1 15.1.1 serial communication channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-2 15.1.2 baud-rate generator/timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-2 15.1.3 interrupt control logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-2 15.2 uart module signal definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-3 15.2.1 transmitter serial data output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-3 15.2.2 receiver serial data input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-3 15.2.3 request-to-send . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-4 15.2.4 clear-to-send . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-4 15.3 operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-4 15.3.1 baud-rate generator/timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-4 15.3.2 transmitter and receiver operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-5 15.3.2.1 transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-5 15.3.2.2 receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-7 toc--8 mcf5249um motorola table of contents paragraph title page number number 15.3.2.3 receiver fifo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-8 15.3.3 looping modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-9 15.3.3.1 automatic echo mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-9 15.3.3.2 local loopback mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-9 15.3.3.3 remote loopback mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-10 15.3.4 multidrop mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-10 15.3.5 bus operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12 15.3.5.1 read cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12 15.3.5.2 write cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12 15.3.5.3 interrupt acknowledge cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12 15.4 register description and programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12 15.4.1 register description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12 15.4.1.1 mode register 1 (umr1n) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-13 15.4.1.2 mode register 2 (umr2n) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-15 15.4.1.3 status registers (usrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-18 15.4.1.4 clock-select registers (uscrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-19 15.4.1.5 command registers (ucrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-20 15.4.1.6 miscellaneous commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-20 15.4.1.6.2 reset receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-21 15.4.1.6.3 reset transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-21 15.4.1.6.4 reset error status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-21 15.4.1.6.5 reset break-change interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-21 15.4.1.6.6 start break . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-21 15.4.1.6.7 stop break . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-21 15.4.1.7 transmitter commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-21 15.4.1.7.1 no action taken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22 15.4.1.7.2 transmitter enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22 15.4.1.7.3 transmitter disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22 15.4.1.7.4 do not use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22 15.4.1.8 receiver commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22 15.4.1.8.1 no action taken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22 15.4.1.8.2 receiver enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22 15.4.1.8.3 receiver disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-23 15.4.1.8.4 do not use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-23 15.4.1.9 receiver buffer registers (ubrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-23 15.4.1.10 transmitter buffer registers (utbn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-23 15.4.1.11 input port change registers uipcrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-24 15.4.1.12 auxiliary control registers (uacrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-24 15.4.1.13 interrupt status registers (uisrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-25 15.4.1.14 interrupt mask registers uimrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-26 15.4.1.15 timer upper preload register (ubg1n) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-27 15.4.1.16 timer upper preload register 2 (ubg2n) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-27 15.4.1.17 interrupt vector registers (uivrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-27 15.4.1.18 input port registers (uipn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-28 15.4.1.19 output port data registers (uop1n) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-28 15.4.2 programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-29 15.4.2.1 uart module initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-29 15.4.2.2 i/o driver example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-29 15.4.2.3 interrupt handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-29 15.5 uart module initialization sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-30 table of contents paragraph title page number number motorola table of contents toc-9 section 16 queued serial peripheral interface (qspi) module . . . . . . . . . . . . . . . . . . . . . .16-1 16.1 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-1 16.2 features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-1 16.3 module description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-1 16.3.1 interface and pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-1 16.3.2 internal bus interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-2 16.4 operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-3 16.4.1 qspi ram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-3 16.4.1.1 transmit ram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5 16.4.1.2 receive ram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5 16.4.1.3 command ram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5 16.4.2 baud rate selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6 16.4.3 transfer delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6 16.4.4 transfer length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7 16.4.5 data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7 16.5 programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8 16.5.1 qspi mode register (qmr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8 16.5.2 qspi delay register (qdlyr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-10 16.5.3 qspi wrap register (qwr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-10 16.5.4 qspi interrupt register (qir) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-11 16.5.5 qspi address register (qar) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12 16.5.6 qspi data register (qdr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-13 16.5.7 command ram registers (qcr0?qcr15) . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-13 16.5.8 programming example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-15 section 17 audio functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-1 17.1 audio interface overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-1 17.1.1 audio interface structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-2 17.1.1.1 audio interrupt mask and interrupt status registers . . . . . . . . . . . . . . . . . . . . . . .17-3 17.2 serial audio interface (iis/eiaj) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5 17.2.1 iis/eiaj transmitter descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-9 17.2.2 iis/eiaj transmitter interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-9 17.2.3 iis/eiaj receiver descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-9 17.3 digital audio interface (ebu) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-10 17.3.1 iec958 receive interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-13 17.3.1.1 audio data reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-13 17.3.1.2 control channel reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-13 17.3.1.3 control channel interrupt (iec958 ?c? channel new frame) . . . . . . . . . . . . . . .17-13 17.3.1.4 validity flag reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-13 17.3.1.5 iec958 exception definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-14 17.3.1.6 ebu extracted clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-14 17.3.1.7 reception of user channel and cd-subcode over iec958 receiver . . . . . . . . .17-14 17.3.1.8 u and q receive register interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-16 17.3.1.9 behavior of user channel receive interface (cd data) . . . . . . . . . . . . . . . . . . .17-16 17.3.1.10 behavior of user channel receive interface (non-cd data) . . . . . . . . . . . . . . . .17-18 17.3.2 iec958 transmit interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-18 17.3.2.1 transmit ?c? channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-18 17.3.2.2 iec958 transmitter exception conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-19 17.3.2.3 iec958-3 ed2 and tech 3250-e standards compliance . . . . . . . . . . . . . . . . . . .17-19 17.3.2.4 transmission of u-channel and cd subcode data . . . . . . . . . . . . . . . . . . . . . . .17-20 17.3.3 cd subcode interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-21 toc--10 mcf5249um motorola table of contents paragraph title page number number 17.3.3.1 free running counter synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-22 17.3.3.2 controlling the sfsy sync position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-22 17.3.4 inserting cd user channel data into iec958 transmit data . . . . . . . . . . . . . . .17-22 17.4 processor interface overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-23 17.4.1 data exchange register descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-23 17.4.2 data exchange register overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-24 17.4.2.1 data in selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-25 17.4.3 pdir and pdor field formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-27 17.4.4 overrun and underrun with pdir and pdor registers . . . . . . . . . . . . . . . . . . .17-27 17.4.5 automatic resynchronization of fifos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-28 17.4.6 audio interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-30 17.4.6.1 audiotick interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-30 17.4.6.2 pdir1, pdir2, and pdir3, exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-30 17.4.6.3 pdor1, pdor2, and pdor3 exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-30 17.4.6.4 audio interrupt routines and timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-32 17.4.7 cd-rom block encoder and decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-33 17.4.7.1 cd-rom decoder interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-35 17.4.7.2 cd-rom encoder interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-36 17.5 dma channel interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-36 17.6 phase/frequency determination and xtrim function . . . . . . . . . . . . . . . . . . . . .17-37 17.6.1 incoming source frequency measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-37 17.6.1.1 filtering for the discrete time oscillator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-40 17.6.2 xtrim option - locking xtal clock to incoming signal . . . . . . . . . . . . . . . . . . . .17-40 17.6.3 xtrim internal logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-40 17.7 audio interface memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-41 section 18 i 2 c modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-1 18.1 i 2 c overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-1 18.2 i 2 c interface features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-1 18.3 i 2 c system configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-2 18.4 i 2 c protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3 18.4.1 start signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3 18.4.2 slave address transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3 18.4.3 data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4 18.4.4 repeated start signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4 18.4.5 stop signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4 18.4.6 arbitration procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4 18.4.7 clock synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4 18.4.8 handshaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5 18.4.9 clock stretching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5 18.5 programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5 18.5.1 i2c address registers (madr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6 18.5.2 i2c frequency divider registers (mfdr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6 18.5.3 i2c control registers (mbcr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-8 18.5.4 i2c status registers (mbsr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-10 18.5.5 i2c data i/o registers (mbdr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-11 18.6 i2c programming examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-12 18.6.1 initialization sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-12 18.6.2 generation of start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-12 18.6.3 post-transfer software response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-13 18.6.4 slave mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-14 table of contents paragraph title page number number motorola table of contents toc-11 18.6.5 arbitration lost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-15 section 19 debug support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-1 19.1 breakpoint (bkpt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-1 19.1.1 debug support signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-1 19.1.2 debug data (ddata[3:0]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-1 19.1.3 development serial clock (dsclk) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-2 19.1.4 development serial input (dsi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-2 19.1.5 development serial output (dso) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-2 19.1.6 processor status (pst[3:0]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-2 19.1.7 processor status clock (pstclk) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-3 19.2 real-time trace support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-4 19.2.1 processor status signal encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-4 19.2.1.1 continue execution (pst = $0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-4 19.2.1.2 begin execution of an instruction (pst = $1) . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-4 19.2.1.3 entry into user mode (pst = $3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-4 19.2.1.4 begin execution of pulse or wddata instructions (pst = $4) . . . . . . . . . . . . .19-4 19.2.1.5 begin execution of taken branch (pst = $5) . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-5 19.2.1.6 begin execution of rte instruction (pst = $7) . . . . . . . . . . . . . . . . . . . . . . . . . . .19-6 19.2.1.7 begin data transfer (pst = $8?$b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-6 19.2.1.8 exception processing (pst = $c) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-6 19.2.1.9 emulator mode exception processing (pst = $d) . . . . . . . . . . . . . . . . . . . . . . . .19-6 19.2.1.10 processor stopped (pst = $e) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-6 19.2.1.11 processor halted (pst = $f) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-6 19.3 background-debug mode (bdm) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-6 19.3.1 cpu halt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-7 19.3.2 bdm serial interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-7 19.3.2.1 receive packet format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-8 19.3.2.2 transmit packet format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-9 19.3.3 bdm command set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-9 19.3.3.1 bdm command set summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-9 19.3.3.2 coldfire bdm commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-9 19.3.3.3 command sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-11 19.3.3.4 command set descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-13 19.3.3.4.1 read address/data register (rareg/rdreg) . . . . . . . . . . . . . . . . . . . . . . . . .19-13 19.3.3.4.2 write address/data register (wareg and wdreg) . . . . . . . . . . . . . . . . . . . . .19-13 19.3.3.4.3 read memory location (read) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-14 19.3.3.4.4 write memory location (write) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-16 19.3.3.4.5 dump memory block (dump) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-17 19.3.3.4.6 fill memory block (fill) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-18 19.3.3.4.7 resume execution (go) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-20 19.3.3.4.8 no operation (nop) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-20 19.3.3.4.9 read control register (rcreg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-21 19.3.3.4.10 write control register (wcreg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-22 19.3.3.4.11 read debug module register (rdmreg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-22 19.3.3.4.12 write debug module register (wdmreg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-23 19.3.3.4.13 unassigned opcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-24 19.3.3.5 bdm accesses of the emac registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-24 19.4 real-time debug support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-25 19.4.1 theory of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-26 19.4.1.1 emulator mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-27 toc--12 mcf5249um motorola table of contents paragraph title page number number 19.4.1.2 debug module hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-27 19.4.1.2.1 reuse of debug module hardware (rev. a) . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-27 19.4.2 programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-28 19.4.2.1 address breakpoint registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-28 19.4.2.2 address attribute trigger register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-29 19.4.2.3 program counter breakpoint register (pbr, pbmr) . . . . . . . . . . . . . . . . . . . . .19-31 19.4.2.4 data breakpoint registers (dbr, dbmr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-32 19.4.2.5 trigger definition register (tdr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-34 19.4.2.6 configuration/status register (csr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-36 19.4.2.7 bdm address attribute (baar) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-39 19.4.3 concurrent bdm and processor operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-40 19.4.4 motorola-recommended bdm pinout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-41 section 20 ieee 1149.1 test access port (jtag) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-1 20.1 jtag overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-1 20.2 jtag signal descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-2 20.2.1 test clock - (tck) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-3 20.2.2 test reset/development serial clock - (trst/dsclk) . . . . . . . . . . . . . . . . . . . .20-3 20.2.3 test mode select/ breakpoint (tms/bkpt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-3 20.2.4 test data input/development serial input - (tdi/dsi) . . . . . . . . . . . . . . . . . . . . . .20-4 20.2.5 test data output/development serial output - (tdo/dso) . . . . . . . . . . . . . . . . .20-4 20.3 tap controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-4 20.4 jtag registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-6 20.4.1 jtag instruction shift register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-6 20.4.1.1 extest instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-6 20.4.1.2 idcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-6 20.4.1.3 sample/preload instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-7 20.4.1.4 clamp instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-7 20.4.1.5 highz instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-7 20.4.1.6 bypass instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-7 20.4.2 idcode register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-8 20.4.3 jtag boundary scan register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-8 20.4.4 jtag bypass register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-9 20.5 restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-9 20.6 disabling ieee 1149.1a standard operation . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-9 20.7 mcf5249 bsdl file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-10 20.8 obtaining the ieee 1149.1a standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-22 section 21 electrical specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-1 21.1 jtag timing definition iis module ac timing specifications . . . . . . . . . . . . . . .21-16 section 22 mechanical data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-1 22.1 package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 22.2. pin assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 appendix a register memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-1 list of tables table title page number number motorola list of tables lot-1 1-1 160 mapbga ball assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5 2-1 mcf5249 signal index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1 2-2 sdram controller signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5 2-3 i 2 c module signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6 2-4 timer module signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7 2-5 serial module signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7 2-6 serial audio interface signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8 2-7 digital audio interface signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9 2-8 subcode interface signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9 2-9 flash memory card signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-10 2-10 queued serial peripheral interface (qspi) signals . . . . . . . . . . . . . . . . . . . . . . . .2-10 2-11 processor status signal encodings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-12 3-1 condition code register (bits 0-4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3 3-2 ccr functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4 3-3 emac instruction summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4 3-4 status register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6 3-5 status bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6 3-6 exception vector assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8 3-7 format field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9 3-8 fault status encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9 3-9 misaligned operand references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13 3-10 move byte and word execution times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14 3-11 move long execution times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14 3-12 one operand instruction execution times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15 3-13 two operand instruction execution times - (macs) . . . . . . . . . . . . . . . . . . . . . . .3-16 3-14 miscellaneous instruction execution times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18 3-15 general branch instruction execution times . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19 3-16 bra, bcc instruction execution times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19 4-1 pllcr register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2 4-2 pllcr bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2 4-3 pll electrical limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 4-4 pllcr bit fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5 4-5 recommended pll settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6 5-1 initial fetch offset vs. clnf bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4 5-2 instruction cache operation as defined by cacr[31,10] . . . . . . . . . . . . . . . . . . . .5-5 5-3 memory map of i-cache registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6 5-4 cache control register (cacr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6 5-5 cache control bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7 5-6 external fetch size based on miss address and clnf . . . . . . . . . . . . . . . . . . . . .5-8 5-7 access control registers (acro, acr1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8 5-8 access control bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9 6-1 sram base address register (rambar0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2 6-2 sram1 base address register (rambar1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2 6-3 cache control bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3 6-4 typical rambar setting examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4 table of tables table title page number number lot-2 mcf5249um motorola 7-1 dram controller registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 7-2 sdram commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 7-3 synchronous dram signal connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4 7-4 dcr field descriptions (synchronous mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6 7-5 dacr0/dacr1 field descriptions (synchronous mode) . . . . . . . . . . . . . . . . . . . .7-7 7-6 dmr0/dmr1 field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9 7-7 sdram interface (8-bit port,10-column address lines) . . . . . . . . . . . . . . . . . . .7-10 7-8 sdram interface (16-bit port,11-column address lines) . . . . . . . . . . . . . . . . . .7-10 7-9 sdram interface (16-bit port,12-column address lines) . . . . . . . . . . . . . . . . . .7-10 7-10 sdram interface (16-bit port, 8-column address lines) . . . . . . . . . . . . . . . . . . .7-11 7-11 sdram interface (16-bit port, 9-column address lines) . . . . . . . . . . . . . . . . . . .7-11 7-12 sdram interface (16-bit port, 10-column address lines) . . . . . . . . . . . . . . . . . .7-11 7-13 sdram interface (16-bit port, 11-column address lines) . . . . . . . . . . . . . . . . . .7-11 7-14 sdram interface (16-bit port, 12-column address lines) . . . . . . . . . . . . . . . . . .7-11 7-15 sdram interface (16-bit port, 13-column-address lines) . . . . . . . . . . . . . . . . . .7-11 7-16 sdram interface (16-bit port, 9-column address lines) . . . . . . . . . . . . . . . . . . .7-12 7-17 sdram interface (16-bit port, 10-column address lines) . . . . . . . . . . . . . . . . . .7-12 7-18 sdram interface (16-bit port, 11-column address lines) . . . . . . . . . . . . . . . . . .7-12 7-19 sdram hardware connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12 7-20 sdram example specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-19 7-21 sdram hardware connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-20 7-22 dcr initialization values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-20 7-23 dacr initialization values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-21 7-24 dmr0 initialization values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-22 7-25 mode register initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-23 8-1 mcf5249 bus signal summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 8-2 reset port settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2 8-3 cf-bus signal summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 8-4 accesses by matches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6 8-5 read cycle states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8 8-6 write cycle states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9 8-7 allowable line access patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11 8-8 power-on reset configuration for cs0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16 9-1 mbar register addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2 9-2 sim memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2 9-3 module base address register (mbar) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4 9-4 module base address bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4 9-5 second module base address register (mbar2) . . . . . . . . . . . . . . . . . . . . . . . . . .9-5 9-6 second module base address bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5 9-7 deviceid register (deviceid) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6 9-8 primary interrupt control register memory map . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7 99-9 interrupt control register (icr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7 9-10 interrupt control bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7 9-11 interrupt priority scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8 9-12 interrupt priority assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8 9-13 interrupt mask register (imr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9 9-14 interrupt mask bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10 9-15 interrupt pending register (ipr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10 9-16 interrupt pending bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10 list of tables table title page number number motorola list of tables lot-3 9-17 secondary interrupt controller registers memory map . . . . . . . . . . . . . . . . . . . . .9-11 9-18 secondary interrupt level programming bit assignment . . . . . . . . . . . . . . . . . . .9-11 9-19 intbase register description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12 9-20 intbase bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12 9-21 spurvec register description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12 9-22 secondary interrupt sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12 9-23 flashmedia interrupt interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-14 9-24 extraint register descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15 9-25 reset status register (rsr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-16 9-26 reset status bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-16 9-27 system protection control register (sypcr) . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-18 9-28 system protection control bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-18 9-29 swt timeout period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-18 9-30 swp and swt bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-19 9-31 software watchdog interrupt vector register (swivr) . . . . . . . . . . . . . . . . . . . .9-19 9-32 software watchdog service register (swsr) . . . . . . . . . . . . . . . . . . . . . . . . . . .9-20 9-33 default bus master register (mpark) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-20 9-34 default bus master selected with park[1:0] . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-21 9-35 round robin (park[1:0] = 00) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-21 9-36 park on master core priority (park[1:0] = 01) . . . . . . . . . . . . . . . . . . . . . . . . . . .9-22 9-37 park on current master priority (park[1:0] = 11) . . . . . . . . . . . . . . . . . . . . . . . . .9-22 9-38 park bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-22 9-39 gpio registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-23 9-40 general purpose input to pin mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-24 9-41 gpio-int-stat, gpio-int-clear and gpio-int-en interrupts . . . . . . . . . . . .9-25 9-42 general-purpose output register bits to pins mapping . . . . . . . . . . . . . . . . . . . .9-27 10-1 accesses by matches in cs control registers . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3 10-2 memory map of chip-select registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5 10-3 chip select address register (csar) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6 10-4 chip select bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6 10-5 chip select mask register (csmr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7 10-6 chip select mask bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7 10-7 chip select control register 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-8 10-8 chip select control register 1 to 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9 10-9 chip select bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9 11-1 programming model for timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3 11-2 timer mode register (tmrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4 11-3 timer mode bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4 11-4 timer reference register (trrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-5 11-5 timer capture register (tcr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6 11-6 timer counter (tcn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6 11-7 timer event register (tern) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6 11-8 timer event bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7 12-1 adc registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2 12-2 adconfig (adconfig) register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3 12-3 adconfig register bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3 12-4 advalue register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-4 12-5 advalue register bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-4 table of tables table title page number number lot-4 mcf5249um motorola 13-1 ideconfig1 register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-3 13-2 ideconfig1 bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-3 13-3 ideconfig register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-5 13-4 ideconfig bit description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-5 13-5 dior, diow, and iordy timing parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-6 13-6 smartmedia timing values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-7 13-7 ide timing values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-9 13-8 flashmedia registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-11 13-9 flashmediaconfig register configuration . . . . . . . . . . . . . . . . . . . . . . . . . .13-11 13-10 flashmedia command registers (memorystick mode) . . . . . . . . . . . . .13-13 13-11 flashmedia command register 1 (secure digital mode) . . . . . . . . . . . .13-13 13-12 flashmedia command register 2 (secure digital mode) . . . . . . . . . . . .13-14 13-13 flashmedia data registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-15 13-14 flashmedia status register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-15 13-15 flashmedia interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-16 14-1 dma signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-2 14-2 memory map dma channel 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-4 14-3 memory map dma channel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-4 14-4 memory map dma channel 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-4 14-5 memory map dma channel 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-4 14-6 memory map (dma controller registers ?bcr24bit = 1) . . . . . . . . . . . . . . . . .14-5 14-7 dmaroute register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-5 14-8 dmaroute register fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-5 14-9 dma3req field definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-6 14-10 dma2req field definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-6 14-11 dma1req field definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-7 14-12 dma0req field definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-8 14-13 source address register (sar) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-8 14-14 destination address register (dar) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-9 14-15 byte count register (bcr)?bcr24bit = 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-10 14-16 byte count register (bcr)?bcr24bit = 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-10 14-17 dma control register (dcr)?bcr24bit = 0 . . . . . . . . . . . . . . . . . . . . . . . . . .14-10 14-18 dma control bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-11 14-19 bwc encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-12 14-20 ssize encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-13 14-21 dsize encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-13 14-22 dma status register (dsr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-14 14-23 dma status bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-14 14-24 dma interrupt vector register (divr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-15 15-1 uart module programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-13 15-2 mode register 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-13 15-3 pmx and pt control bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-14 15-4 mode register 1 bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-14 15-5 b/cx control bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-15 15-6 mode register 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-15 15-7 mode register 2 bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-16 15-8 status registers (usr0 and usr1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-18 15-9 status bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-18 list of tables table title page number number motorola list of tables lot-5 15-10 clock select register (ucsrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-19 15-11 clock select bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-20 15-12 command register (ucrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-20 15-13 miscx control bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-20 15-14 tcx control bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22 15-15 rcx control bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22 15-16 receiver buffer (urbn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-23 15-17 receiver buffer bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-23 15-18 transmitter buffer (utbn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-23 15-19 transmitter buffer bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-24 15-20 input port change register (uipcrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-24 15-21 input port change bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-24 15-22 auxiliary control register (uacrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-25 15-23 auxiliary control bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-25 15-24 interrupt status register (uisrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-25 15-25 interrupt status bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-26 15-26 interrupt mask register (uimrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-26 15-27 interrupt mask bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-27 15-28 interrupt vector register (uivrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-27 15-29 interrupt vector bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-28 15-30 input port register (uipn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-28 15-31 interrupt vector bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-28 15-32 output port data registers (uop1n) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-28 15-33 output port data bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-29 15-34 output port data registers (uop0n) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-29 16-1 qspi input and output signals and functions . . . . . . . . . . . . . . . . . . . . . . . . . . .16-2 16-2 qspi_clk frequency as function of cpu clock and baud rate . . . . . . . . . . . .16-6 16-3 qspimr field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8 16-4 qdlyr field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-10 16-5 qwr field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-11 16-6 qir field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12 16-7 qcr0?qcr15 field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-14 17-1 interrupt register addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4 17-2 interrupt register description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4 17-3 interrupten3 interruptclear3, interruptstat3 register description . . . . . . . . . . . . .17-5 17-4 iis1 configuration registers (0x10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-6 17-5 iis2 configuration registers (0x14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-6 17-6 iis3,4 configuration registers (0x18, 0x1c) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-6 17-7 iis configuration bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-7 17-8 ebu1config register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-10 17-9 ebu1config register bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-11 17-10 ebu2config register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-12 17-11 ebu2config register bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-12 17-12 eburcvcchannel register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-13 17-13 uchannel receive and qchannel receive registers . . . . . . . . . . . . . . . . . . . . .17-15 17-14 u channel receive and q channel receive bit descriptions . . . . . . . . . . . . . . .17-15 17-15 cdtextcontrol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-15 17-16 cd-subcode register bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-15 17-17 correlation between zero bits and sync symbols . . . . . . . . . . . . . . . . . . . . . . .17-17 table of tables table title page number number lot-6 mcf5249um motorola 17-18 ebu1txcchannel registers addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-19 17-19 formatting of ebuout1 (consumer ?c? channel) . . . . . . . . . . . . . . . . . . . . . . .17-19 17-20 formatting of ebuout2 - professional ?c? channel . . . . . . . . . . . . . . . . . . . . . .17-19 17-21 uchannel transmit register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-20 17-22 cd-subcode register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-20 17-23 data exchange register descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-23 17-24 dataincontrol register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-25 17-25 dataincontrol bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-25 17-26 pdir1-l, pdir3-l, pdor1-l, pdor2-l formatting . . . . . . . . . . . . . . . . . . . . .17-27 17-27 pdir1-r, pdir3-r, pdor1-r, pdor2-r formatting . . . . . . . . . . . . . . . . . . . .17-27 17-28 pdir2, pdor3 formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-27 17-29 audioglob register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-28 17-30 audioglob register fields (0xce) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-29 17-31 interrupt register description (0x94, 0x98) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-31 17-32 blockcontrol register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-33 17-33 blockcontrol bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-34 17-34 swap control in cd-rom encoder/decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-35 17-35 dma config register address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-37 17-36 dma config bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-37 17-37 phaseconfig and frequency measure register addresses . . . . . . . . . . . . . . . .17-38 17-38 phaseconfig register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-39 17-39 phaseconfig bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-39 17-40 phaseconfig register description (0xa0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-39 17-41 xtrim register address and description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-40 17-42 audio interface memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-41 18-1 i 2c interfaces programmer?s model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5 18-2 madr register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6 18-3 madr bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6 18-4 mfdr register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-7 18-5 mfdr bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-7 18-6 i 2 c prescaler values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-7 18-7 mbcr register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-8 18-8 mbcr bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-9 18-9 mbsr register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-10 18-10 mbsr bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-10 18-11 mbdr register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-11 19-1 processor status encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-3 19-2 receive bdm packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-8 19-3 cpu-generated command responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-8 19-4 receive bdm bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-9 19-5 transmit bdm packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-9 19-6 transmit bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-9 19-7 bdm command summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-10 19-8 bdm command format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-11 19-9 bdm bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-11 19-10 bdm size field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-11 19-11 wareg/wdreg command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-14 19-12 byte fill command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-19 19-13 word fill command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-19 list of tables table title page number number motorola list of tables lot-7 19-14 long fill command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-19 19-15 go command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-20 19-16 nop command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-20 19-17 rc encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-22 19-18 definition of drc encoding--read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-23 19-19 definition of drc encoding--write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-24 19-20 ddata[3:0], csr[31:28] breakpoint response . . . . . . . . . . . . . . . . . . . . . . . . .19-26 19-21 shared bdm/breakpoint hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-28 19-22 address breakpoint low register (ablr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-29 19-23 address breakpoint high register (abhr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-29 19-24 address attribute trigger register (aatr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-30 19-25 address attribute trigger bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-30 19-26 program counter breakpoint register (pbr) . . . . . . . . . . . . . . . . . . . . . . . . . . .19-32 19-27 program counter breakpoint mask register (pbmr) . . . . . . . . . . . . . . . . . . . . .19-32 19-28 data breakpoint register (dbr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-33 19-29 data breakpoint mask register (dbmr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-33 19-30 access and operand data location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-34 19-31 trigger definition register (tdr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-35 19-32 trigger definition bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-35 129-33 configuration/status register (csr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-37 19-34 configuration/status bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-37 19-35 bdm address attribute register (baar) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-39 19-36 bdm address attribute (baar) bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . .19-40 20-1 jtag pin descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-3 20-2 jtag instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-6 20-3 id code register command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-8 20-4 id code bit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-8 21-1 maximum ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-1 21-2 operating temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-1 21-3 dc electrical specifications (vcc = 3.3 vdc + 0.3 vdc) . . . . . . . . . . . . . . . . . . . . .21-2 21-4 160 mapbga ball assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-3 21-5 clock timing specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-4 21-6 input ac timing specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-5 21-7 output ac timing specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-5 21-8 debug ac timing specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-8 21-9 timer module ac timing specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-9 21-10 uart module ac timing specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-10 21-11 i 2 c-bus input timing specifications between scl and sda . . . . . . . . . . . . . . .21-11 21-12 i 2 c-bus output timing specifications between scl and sda . . . . . . . . . . . . .21-11 21-14 general-purpose i/o port ac timing specifications . . . . . . . . . . . . . . . . . . . . . .21-13 21-15 ieee 1149.1 (jtag) ac timing specifications . . . . . . . . . . . . . . . . . . . . . . . . . .21-14 21-16 sclk input, sdatao output timing specifications . . . . . . . . . . . . . . . . . .21-16 21-17 sclk output, sdata0 output timing specifications . . . . . . . . . . . . . . . . .21-16 21-18 sclk input, sdatai input timing specifications . . . . . . . . . . . . . . . . . . . . .21-17 22-1 144 qfp pin assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-2 22-2 160 mapbga pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-6 22-3 160 mapbga pin assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-7 table of tables table title page number number lot-8 mcf5249um motorola a-1 cpu memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-1 a-2 mbar address space memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-1 a-3 audio interface memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-4 a-4 gpio and interrupt status memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-6 a-5 a/d, mbus2 and memory stick memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-7 list of figures figure title page number number motorola list of figures lof-1 1-1 mcf5249 block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2 3-1 v2 coldfire processor core pipelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1 3-2 user programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3 3-3 supervisor programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5 3-4 vector base register (vbr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6 3-5 exception stack frame form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9 4-1 phase-locked loop module block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1 5-1 instruction cache block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2 7-1 synchronous dram controller block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2 7-2 mcf5249 sdram interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5 7-3 dram control register (dcr) (synchronous mode) . . . . . . . . . . . . . . . . . . . . . . .7-5 7-4 dacr0 and dacr1 (synchronous mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7 7-5 dram controller mask registers (dmr0 and dmr1) . . . . . . . . . . . . . . . . . . . . . .7-9 7-6 burst read sdram access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-13 7-7 burst write sdram access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-14 7-8 synchronous, continuous page-mode access?consecutive reads . . . . . . . . . .7-15 7-9 synchronous, continuous page-mode access?read after write . . . . . . . . . . . .7-16 7-10 auto-refresh operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-17 7-11 self-refresh operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-17 7-12 mode register set (mrs) command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-19 7-13 initialization values for dcr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-20 7-14 sdram configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-21 7-15 dacr register configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-21 7-16 dmr0 register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-22 7-17 mode register mapping to mcf5249 a[31:0] . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-23 8-1 connections for external memory port sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3 8-2 signal relationship to bclk for non-dram access . . . . . . . . . . . . . . . . . . . . . . . .8-5 8-3 read cycle flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-7 8-4 basic read bus cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-7 8-5 write cycle flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9 8-6 basic write bus cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9 8-7 back-to-back bus cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10 8-8 line read burst (one wait cycle) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12 8-9 line read burst (no wait cycles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12 8-10 line write burst (no wait cycles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-13 8-11 line read burst-inhibited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-13 8-12 line write burst with one wait state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14 8-13 line write burst-inhibited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14 8-14 misaligned longword transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15 8-15 misaligned word transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15 8-16 master reset timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16 8-17 software watchdog reset timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-17 9-1 mcf5249 unterminated access recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-17 9-2 general-purpose pin logic for pin ddata3/gpio34 . . . . . . . . . . . . . . . . . . . . . . . . .9-27 11-1 timer block diagram module operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2 12-1 adc with on-chip and external parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2 13-1 bus setup with ide and smartmedia interface . . . . . . . . . . . . . . . . . . . . . . . . . . .13-1 13-2 buffer enables (bufenb1 and bufenb2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2 13-3 dior and sre timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-5 13-4 non-iordy controlled ide/smartmedia ta timing . . . . . . . . . . . . . . . . . . . . . . .13-6 13-5 cs2 (dior, diow) and cs3 (sre, swe) cycle timing . . . . . . . . . . . . . . . . . . .13-6 list of figures figure title page number number motorola list of figures lof-2 13-6 smartmedia timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-7 13-7 ide timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-8 13-8 flashmedia block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-10 13-9 one interface shift register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-12 13-10 reading data from memorystick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-17 13-11 reading data from memorystick timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-17 13-12 writing data to memorystick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-18 13-13 writing data to memorystick timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-18 13-14 interrupt from memorystick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-19 13-15 interrupt from memorystick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-19 13-16 sent command to card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-20 13-17 write data to card with busy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-21 13-18 write data to card without busy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-22 13-19 read data from card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-23 14-1 dma signal diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-1 14-2 dual address transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-3 15-1 uart block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-1 15-2 external and internal interface signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-3 15-3 baud-rate timer generator diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-4 15-4 transmitter and receiver functional diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-5 15-5 transmitter timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-6 15-6 receiver timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-7 15-7 looping modes functional diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-10 15-8 multidrop mode timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-11 15-9 uart software flowchart (1 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-31 15-10 uart software flowchart (2 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-32 15-11 uart software flowchart (3 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-33 15-12 uart software flowchart (4 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-34 15-13 uart software flowchart (5 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-35 16-1 qspi block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-2 16-2 qspi ram model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-4 16-3 qspi mode register (qspimr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8 16-4 qspi clocking and data transfer example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9 16-5 qspi delay register (qdlyr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-10 16-6 qspi wrap register (qwr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-10 16-7 qspi interrupt register (qir) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-11 16-8 qspi address register (qar) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-13 16-9 qspi data register (qdr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-13 16-10 command ram registers (qcr0?qcr15) . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-14 16-11 qspi timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-15 17-1 audio interface block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-2 17-2 iis/eiaj timing diagram (16 sclk edges per word) . . . . . . . . . . . . . . . . . . . . . .17-9 17-3 iis/eiaj timing diagram (24 or 32 sclk edges per word) . . . . . . . . . . . . . . . . . .17-10 17-4 cd-subcode interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-20 17-5 data format on cd-subcode interface out . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-21 17-6 processor/audio module interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-23 17-7 automatic resynchronization fsm of left-right fifos . . . . . . . . . . . . . . . . . . . . .17-28 17-8 audio transmit / receive fifos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-33 17-9 block decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-35 17-10 block encoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-36 17-11 frequency measurement circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-38 list of figures figure title page number number motorola list of figures lof-3 17-12 xtrim external circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-40 17-13 pdm modulator used on xtrim output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-41 18-1 i 2c module block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-2 18-2 i2c standard communication protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3 18-3 synchronized clock scl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5 18-4 flow-chart of typical i2c interrupt routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-16 19-1 processor/debug module interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-1 19-2 example pst/ddata diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-5 19-3 1bdm serial transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-8 19-4 command sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-12 19-5 command/result formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-13 19-6 read a/d register command sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-13 19-7 write a/d register command sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-14 19-8 wareg/wdreg command format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-14 19-9 read command/result format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-15 19-10 read memory location command sequence . . . . . . . . . . . . . . . . . . . . . . . . . . .19-15 19-11 write memory location command sequence . . . . . . . . . . . . . . . . . . . . . . . . . . .19-16 19-12 dump command/result format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-17 19-13 dump memory block command sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-18 19-14 fill memory block command sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-19 19-15 resume execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-20 19-16 no operation command sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-20 19-17 rcreg command/result formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-21 19-18 wcreg command sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-22 19-19 write control register command sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-22 19-20 rdmreg command/result formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-23 19-21 read debug module register command sequence . . . . . . . . . . . . . . . . . . . . . .19-23 19-22 wdmreg bdm command format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-23 19-23 write debug module register command sequence . . . . . . . . . . . . . . . . . . . . . .19-24 19-24 read control register command sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-25 19-25 debug programming mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-28 19-26 recommended bdm connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-41 20-1 jtag test logic block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-2 20-2 jtag tap controller state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5 20-3 disabling jtag in jtag mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-9 20-4 disabling jtag in debug mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-10 21-1 clock timing definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-4 21-2 input/output timing definition-i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-6 21-3 input/output timing definition-iii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-7 21-4 debug timing definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-8 21-5 timer module timing definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-9 21-6 uart timing definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-10 21-7 i2c timing definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-12 21-8 i 2c and system clock timing relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-13 21-9 general-purpose parallel port timing definition . . . . . . . . . . . . . . . . . . . . . . . . .21-13 21-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-15 21-11 sclk input, sdata output timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-16 21-12 sclk output, sdatao output timing diagram . . . . . . . . . . . . . . . . . . . . . . . . .21-16 22-1 144 qfp package (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-12 22-2 144 qfp package (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-13 22-3 144 qfp package (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-14 list of figures figure title page number number motorola list of figures lof-4 22-4 160 bga mechanical package (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-15 22-6 160 bga mechanical package (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-16 motorola section 1 mcf5249 introduction 1-1 section 1 mcf5249 introduction 1.1 mcf5249 overview this document provides an overview of the mcf5249 coldfire ? processor and general descriptions of the mcf5249 features and modules. the mcf5249 was designed as a system controller/decoder for mp3 music players, especially portable mp3 cd players. the 32-bit coldfire core with enhanced multiply accumulate (emac) unit provides optimum performance and code density for the combination of control code and signal processing required for mp3 decode, file management, and system control. low power features include a hardwired cd rom decoder, advanced 0.18um cmos process technology, 1.8v core power supply, and on-chip 96kbyte sram. mp3 decode requires less than 20mhz cpu bandwidth and runs in on-chip sram with external access only for data input and output. the mcf5249 is also an excellent general purpose system controller with over 125 dhrystone 2.1 mips @ 140mhz performance at a very competitive price. the integrated peripherals and emac allow the mcf5249 to replace both the microcontroller and the dsp in certain applications. most peripheral pins can also be remapped as general purpose i/o pins. 1.2 mcf5249 feature introduction the mcf5249 integrated microprocessor combines a version 2 coldfire ? processor core operating at 140mhz with the following modules. dma controller with 4 dma channels integrated enhanced multiply-accumulate unit (emac) 8-kbyte direct mapped instruction cache 96-kbyte sram (a 64k and a 32k bank) operates from external crystal oscillator supports 16-bit wide sdram memories serial audio interface which supports iis and eiaj audio protocols digital audio transmitter and two receivers compliant with iec958 audio protocol cd-rom and cd-rom xa block decoding and encoding function two uarts queued serial peripheral interface (qspi) (master only) two timers ide and smartmedia interfaces analog/digital converter flash memory card interface two i 2 c modules 1 system debug support general purpose i/o pins shared with other functions 1. i 2 c is a proprietary philips bus. 1-2 mcf5249um motorola mcf5249 block diagram 1.8v core, 3.3v i/o 160 pin mapbga package (qualified at 140 mhz) and 144 pin qfp package (qualified at 120 mhz) 1.3 mcf5249 block diagram figure 1-1 mcf5249 block diagram debug module w/ jtag coldfire v2 core (160 bga 140 mhz) (144 qfp 120 mhz) instruction cache sram0 sram1 dma 5x08 arbiter timer i 2 c dual uart 5x08 interrupt s/dram interface external bus translator clock multiplied pll interrupt controller audio interfaces standard coldfire peripheral blocks 32k 64k uart interface i 2 c interface timer support adc flash memory/ card interface memorystick/ interface serial audio interface bufen_b1 (s)dram sram mux ide smartmedia ide bufen_b2 swe sre ide-dior ide-diow ide-iordy ebuin3_adin0_gpi38 ebuin4_adin1_gpi39 rxd2_adin2_gpi28 cts2_adin3_gpi31 tout1_adout_gpi35 securedigital qspi interface qspi_din qspi_dout qspi_cs[3:0] qspi_clk bufen1_b bufen2_b qspi_din qspi_dout ebuin3/adin0_gp138 ebuin4/adin1_gp139 rxd2/adin2/gp128 cts2/adin3/gp131 tout1/adout/gp135 mcf5249 feature details motorola section 1 mcf5249 introduction 1-3 1.4 mcf5249 feature details the primary features of the mcf5249 integrated processor include the following: coldfire v2 processor core operating at 140mhz ? clock-doubled version 2 microprocessor core ? 32-bit internal data bus, 16 bit external data bus ? 16 user-visible, 32-bit general-purpose registers ? supervisor/user modes for system protection ? vector base register to relocate exception-vector table ? optimized for high-level language constructs dma controller ? four fully programmable channels: two dedicated to the audio interface module and two dedicated to the uart module (external requests are not supported.) ? supports dual- and single-address transfers with 32-bit data capability ? two address pointers that can increment or remain constant ? 16-/24-bit transfer counter ? operand packing and unpacking support ? auto-alignment transfers supported for efficient block movement ? supports bursting and cycle stealing ? all channels support memory to memory transfers ? interrupt capability ? provides two clock cycle internal access enhanced multiply-accumulator unit ? single-cycle multiply-accumulate operations for 32 x 32 bit and 16 x 16 bit operands ? support for signed, unsigned, integer, and fixed-point fractional input operands ? four 48-bit accumulators to allow the use of a 40-bit product ? the addition of 8 extension bits to increase the dynamic number range ? fast signed and unsigned integer multiplies 8-kbyte direct mapped instruction cache ? clocked at core clock frequency ? flush capability ? non-blocking cache provides fast access to critical code and data 96-kbyte sram ? provides one-cycle access to critical code and data ? split into two banks, sram0 (32k), and sram1 (64k) ? dma requests to/from internal sram1 supported crystal trim ? the xtrim output can be used to trim an external crystal oscillator circuit which would allow lock with an incoming iec958 or serial audio signal audio interfaces ? iec958 input and output ? four serial philips iis/sony eiaj interfaces ? one with input and output, one with output only, two with input only (three inputs, two outputs) ? master and slave operation 1-4 mcf5249um motorola mcf5249 feature details cd text interface ? allows the interface of cd subcode (transmitter only) dual universal synchronous/asynchronous receiver/transmitter (dual uart) ? full duplex operation ? baud-rate generator ? modem control signals: clear-to-send (cts) and request-to-send (rts) ? dma interrupt capability ? processor-interrupt capability queued serial peripheral interface (qspi) ? programmable queue to support up to 16 transfers without user intervention ? supports transfer sizes of 8 to 16 bits in 1-bit increments ? four peripheral chip-select lines for control of up to 15 devices ? baud rates from 273 kbps to 15 mbps at 140mhz ? programmable delays before and after transfers ? programmable clock phase and polarity ? supports wraparound mode for continuous transfers ? master mode only dual 16-bit general-purpose multimode timers ? clock source selectable from external, cpu clock/2 and cpu clock/32. ? 8-bit programmable prescaler ? 2 timer inputs and 2 outputs ? processor-interrupt capability ? 14.3 ns resolution with cpu clock at 140mhz ide/ smartmedia interface ? allows direct connection to an ide hard drive or other ide peripheral analog/digital converter ? 12-bit resolution ? 4 muxed inputs flash memory card interface ? allows connection to sony memorystick compatible devices ? support sd cards and other types of flash media dual i 2 c interfaces ? interchip bus interface for eeproms, lcd controllers, a/d converters, keypads ? master and slave modes, support for multiple masters ? automatic interrupt generation with programmable level system debug support ? real-time instruction trace for determining dynamic execution path ? background debug mode (bdm) for debug features while halted ? debug exception processing capability ? real-time debug support 160 mapbga ball assignments motorola section 1 mcf5249 introduction 1-5 system interface ? glueless bus interface and dramc support for interface to 16-bit for dram, sram, rom, flash, and i/o devices ? two programmable chip-select signals for static memories or peripherals with programmable wait states and port sizes. ? two dedicated chip selects for 16-bit wide dram/sdram. ? cs0 is active after reset to provide boot-up from external flash/rom. ? two dedicated chip selects (cs2 and cs3) are used for the ide and/or smartmedia interface ? programmable interrupt controller (low interrupt latency, eight external interrupt requests, programmable autovector generator) ? 44 programmable general-purpose inputs (for the 160 mapbga package) ? 46 programmable general-purpose outputs (for the 160 mapbga package) ? ieee 1149.1 test (jtag) module clocking ? clock-multiplied pll, programmable frequency 1.8v core, 3.3v i/o 160 pin mapbga package (qualified at 140 mhz) and 144 pin qfp package (qualified at 120 mhz) 1.5 160 mapbga ball assignments the following signals are not available on the 144 qfp package. table 1-1 160 mapbga ball assignments 160mapbga ball number function gpio e3 cmd_sdio2 gpio34 g4 sdata0_sdio1 gpio54 h3 rsto/sdata2_bs2 k3 a25 gpio8 l4 qspi_cs1 gpio24 l8 qspi_cs3 gpio22 n8 sdram_cs2 gpio7 p9 ebuout2 gpo 37 k11 bufenb2 gpio17 g12 subr gpio 53 f13 sfsy gpio 52 f12 rck gpio 51 e8 sre gpio11 b8 lrck3 gpio 45 e7 swe gpio12 a7 sclk3 gpio 49 1-6 mcf5249um motorola mcf5249 functional overview 1.6 mcf5249 functional overview 1.6.1 coldfire v2 core the coldfire processor version 2 core consists of two independent, decoupled pipeline structures to maximize performance while minimizing core size.the instruction fetch pipeline (ifp) is a two-stage pipeline for prefetching instructions. the prefetched instruction stream is then gated into the two-stage operand execution pipeline (oep), which decodes the instruction, fetches the required operands, and then executes the required function. because the ifp and oep pipelines are decoupled by an instruction buffer that serves as a fifo queue, the ifp can prefetch instructions in advance of their actual use by the oep, which minimizes time stalled waiting for instructions. the oep is implemented in a two-stage pipeline featuring a traditional risc data path with a dual-read-ported register file feeding an arithmetic/logic unit (alu). 1.6.2 dma controller the mcf5249 provides four fully programmable dma channels for quick data transfer. single and dual address mode is supported with the ability to program bursting and cycle stealing. data transfer is selectable as 8, 16, 32, or 128-bits. packing and unpacking is supported. two internal audio channels and the dual uart can be used with the dma channels. all channels can perform memory to memory transfers. the dma controller has a user-selectable, 24- or 16-bit counter and a programmable dma exception handler. external requests are not supported. 1.6.3 enhanced multiply and accumulate module (emac) the integrated emac unit provides a common set of dsp operations and enhances the integer multiply instructions in the coldfire architecture. the emac provides functionality in three related areas: 1. faster signed and unsigned integer multiplies 2. new multiply-accumulate operations supporting signed and unsigned operands 3. new miscellaneous register operations multiplies of 16x16 and 32x32 with 48-bit accumulates are supported in addition to a full set of extensions for signed and unsigned integers plus signed, fixed-point fractional input operands. the emac has a single-clock issue for 32x32-bit multiplication instructions and implements a four-stage execution pipeline. 1.6.4 instruction cache the instruction cache improves system performance by providing cached instructions to the execution unit in a single clock. the mcf5249 processor uses a 8k-byte, direct-mapped instruction cache to achieve 125 mips at 140 mhz. the cache is accessed by physical addresses, where each 16-byte line consists of an address tag and a valid bit. the instruction cache also includes a bursting interface for 16-bit and 8-bit port sizes to quickly fill cache lines. 1.6.5 internal 96-kbyte sram the 96-kbyte on-chip sram is split over two banks, sram0 (64k) and sram1 (32k). it provides one clock-cycle access for the coldfire core. this sram can store processor stack and critical code or data segments to maximize performance. memory in the second bank can be accessed under dma. mcf5249 functional overview motorola section 1 mcf5249 introduction 1-7 1.6.6 dram controller the mcf5249 dram controller provides a glueless interface for up to two banks of dram, each of which can be up to 32 mbytes. the controller supports a 16-bit data bus. a unique addressing scheme allows for increases in system memory size without rerouting address lines and rewiring boards. the controller operates in page mode, non-page mode, and burst-page mode and supports sdrams. 1.6.7 system interface the mcf5249 provides a glueless interface to 16-bit port size sram, rom, and peripheral devices with independent programmable control of the assertion and negation of chip-select and write-enable signals. the mcf5249 also supports bursting roms. 1.6.8 external bus interface the bus interface controller transfers information between the coldfire core or dma and memory, peripherals, or other devices on the external bus. the external bus interface provides 23 bits of address bus space, a 16-bit data bus, output enable, and read/write signals. this interface implements an extended synchronous protocol that supports bursting operations. 1.6.9 serial audio interfaces the mcf5249 digital audio interface provides four serial philips iis/sony eiaj interfaces. one interface is a 4-pin (1 bit clock, 1 word clock, 1 data in, 1 data out), the other three interfaces are 3-pin (1 bit clock, 1 word clock, 1 data in or out). the serial interfaces have no limit on minimum sampling frequency. maximum sampling frequency is determined by the maximum frequency on the bit clock input. (1/3 the frequency of the internal system clock.) 1.6.10 iec958 digital audio interfaces the mcf5249 has two digital audio input interfaces, and one digital audio output interface. there are four digital audio input pins and two digital audio output pins. an internal multiplexer selects one of the four inputs to the digital audio input interface. there is one digital audio output interface with two iec958 outputs. one output carries the professional ?c? channel (channel status), and the other carries the consumer ?c? channel. all other bits (audio data, user channel bits, validity flag, etc) are identical. the iec958 output can take the output from the internal iec958 generator, or multiplex out one of the four iec958 inputs. 1.6.11 audio bus the audio interfaces connect to an internal bus that carries all audio data. each receiver places its received data on the audio bus and each transmitter takes data from the audio bus for transmission. each transmitter has a source select register. in addition to the audio interfaces, there are six cpu accessible registers connected to the audio bus. three of these registers allow data reads from the audio bus and allow selection of the audio source. the other three registers provide a write path to the audio bus and can be selected by transmitters as the audio source. through these registers, the cpu has access to the audio samples for processing. 1-8 mcf5249um motorola mcf5249 functional overview audio can be routed from a receiver to a transmitter without the data being processed by the core so the audio bus can be used as a digital audio data switch. the audio bus can also be used for audio format conversion. 1.6.12 cd-rom e ncoder/decoder the mcf5249 is capable of processing cd-rom sectors in hardware. processing is compliant with cd-rom and cd-rom xa standards. the cd-rom decoder performs following functions in hardware: sector sync recognition descrambling of sectors verification of the crc checksum for mode 1, mode 2 form 1, and mode 2 form 2 sectors third-layer error correction is not performed the cd-rom encoder performs following functions in hardware: sector sync recognition scrambling of sectors insertion of the crc checksum for mode 1, mode 2 form 1, and mode 2 form 2 sectors. third-layer error encoding needs to be done in software. this can use approximately 5-10 mhz of performance for single-speed. 1.6.13 dual uart module two full-duplex uarts with independent receive and transmit buffers are in this module. data formats can be 5, 6, 7, or 8 bits with even, odd, or no parity, and up to 2 stop bits in 1/16 increments. four-byte receive buffers and two-byte transmit buffers minimize cpu service calls. the dual uart module also provides several error-detection and maskable-interrupt capabilities. modem support includes request-to-send (rts ) and clear-to-send (cts ) lines. the system clock provides the clocking function from a programmable prescaler. users can select full duplex, auto-echo loopback, local loopback, and remote loopback modes. the programmable dual uarts can interrupt the cpu on various normal or error-condition events. 1.6.14 queued serial peripheral interface qspi the qspi module provides a serial peripheral interface with queued transfer capability. it supports up to 16 stacked transfers at a time, making cpu intervention between transfers unnecessary. transfers of up to 17.5 mbits/second are possible at a cpu clock of 140 mhz. the qspi supports master mode operation only. 1.6.15 timer module the timer module includes two general-purpose timers, each of which contains a free-running 16-bit timer for use in any of three modes: 1. input capture. this mode captures the timer value with an external event. 2. output compare. this mode triggers an external signal or interrupts the cpu when the timer reaches a set value 3. event counter. this mode counts external events. mcf5249 functional overview motorola section 1 mcf5249 introduction 1-9 the timer unit has an 8-bit prescaler that allows programming of the clock input frequency, which is derived from the system clock. in addition to the 1 and 16 clock derived from the bus clock (cpu clock / 2), the programmable timer-output pins either generate an active-low pulse or toggle the outputs. 1.6.16 ide and smartmedia interfaces the mcf5249 system bus allows connection of an ide hard disk drive and smartmedia flash card with a minimum of external hardware. the external hardware consists of bus buffers for address and data and are intended to reduce the load on the bus and prevent sdram and flash accesses to propagate to the ide bus. the control signals for the buffers are generated in the mcf5249. 1.6.17 analog/digital converter (adc) the four channel adc is based on the sigma-delta concept with 12-bit resolution. the digital portion of the adc is provided internally. the analog voltage comparator must be provided externally as well as an external integrator circuit (resistor/capacitor) which is driven by the adc output. a software interrupt is provided when the adc measurement cycle is complete. 1.6.18 flash memory card interface the interface is sony memorystick and securedigital compatible. however, there is no hardware support for magicgate ? . 1.6.19 i 2 c module the two-wire i 2 c bus interface, which is compliant with the philips i 2 c bus standard, is a bidirectional serial bus that exchanges data between devices. the i 2 c bus minimizes the interconnection between devices in the end system and is best suited for applications that need occasional bursts of rapid communication over short distances among several devices. bus capacitance and the number of unique addresses limit the maximum communication length and the number of devices that can be connected. 1.6.20 chip-selects there are four programmable chip selects on the mcf5249: two programmable chip-select outputs (cs0 and cs1) provide signals that enable glueless connection to external memory and peripheral circuits. the base address, access permissions, and automatic wait-state insertion are programmable with configuration registers. these signals also interface to 16-bit ports. two dedicated chip selects (cs2 and cs3) are used for the ide and/or smartmedia interface cs0 is active after reset to provide boot-up from external flash/rom. 1.6.21 gpio interface a total of 44 general purpose inputs and 46 general purpose outputs are available. these are multiplexed with various other signals. eight of the gpio inputs have edge sensitive interrupt capability. 1.6.22 interrupt controller the mcf5249 has a primary and a secondary interrupt controller. these interrupt controllers handle interrupts from all internal interrupt sources. in addition, there are 8 gpios where external interrupts can 1-10 mcf5249um motorola mcf5249 functional overview be generated on the rising or falling edge of the pin. all interrupts are autovectored and interrupt levels are programmable. 1.6.23 jtag to help with system diagnostics and manufacturing testing, the mcf5249 includes dedicated user-accessible test logic that complies with the ieee 1149.1a standard for boundary scan testability, often referred to as joint test action group, or jtag. for more information, refer to the ieee 1149.1a standard. motorola provides bsdl files for jtag testing. 1.6.24 system debug interface the coldfire processor core debug interface supports real-time instruction trace and debug, plus background-debug mode. a background-debug mode (bdm) interface provides system debug. in real-time instruction trace, four status lines provide information on processor activity in real time (pst pins). a four-bit wide debug data bus (ddata) displays operand data and change-of-flow addresses, which helps track the machine?s dynamic execution path. 1.6.25 crystal and on-chip pll typically, an external 16.92 mhz or 33.86 mhz clock input is used for cd r/w applications, while an 11.2896 mhz clock is more practical for portable cd player applications. however, the on-chip programmable pll, which generates the processor clock, allows the use of almost any low frequency external clock (5-35 mhz). two clock outputs (mclk1 and mclk2) are provided for use as audio master clock. the output frequencies of both outputs are programmable to fxtal, fxtal/2, fxtal/3, and fxtal/4. the fxtal/3 option is only available when the 33.86 mhz crystal is connected. the mcf5249 supports vco operation of the oscillator by means of a 16-bit pulse density modulation output. using this mode, it is possible to lock the oscillator to the frequency of an incoming iec958 or iis signal. the maximum trim depends on the type and design of the oscillator. typically a trim of +/- 100 ppm can be achieved with a crystal oscillator and over +/- 1000 ppm with an lc oscillator. motorola section 2 signal description 2-1 section 2 signal description 2.1 introduction this section describes the mcf5249 input and output signals. the signal descriptions as shown in table 2-1 are grouped according to relevant functionality. table 2-1 mcf5249 signal index signal name mnemonic function input/ output reset state address a[23:1] a[25]/gpo8 23 address bus lines, address line 25 multiplexed with gpo8 out x read-write control rw_b bus write enable - indicates if read or write cycle in progress out h output enable oe output enable for asynchronous memories connected to chip selects out negated data d[31:16] data bus used to transfer word data in/out hi-z synchronous row address strobe sdras row address strobe for external sdram. out negated synchronous column address strobe sdcas column address strobe for external sdram out negated sdram write enable sdwe write enable for external sdram out negated sdram upper byte enable sdudqm indicates during write cycle if high byte is written out sdram lower byte enable sdldqm indicates during write cycle if low byte is written out sdram chip selects sdramcs1 sdram chip select out negated sdram chip selects sdramcs2/gpio7 sdram chip select in/out negated sdram clock enable bclke sdram clock enable out system clock sclk/gpio10 sdram clock output in/out isa bus read strobes cs2/ide-dior/gpio13 cs3/sre/gpio11 there are 2 isa bus read strobes and 2 isa bus write strobes. they allow connection of two independent isa bus peripherals, e.g. an ide slave device and a smartmedia card in/out isa bus write strobes ide-diow/gpio14 swe/gpio12 in/out isa bus wait signal ide-iordy/gpio16 isa bus wait line - available for both busses in/out chip selects[1:0] cs0 cs 1/gpio58 enables peripherals at programmed addresses. cs [1:0]. cs[ 0] provides boot rom selection out in/out negated buffer enable 1 bufenb1 /gpio57 two programmable buffer enables allow seamless steering of external buffers to split data and address bus in sections. in/out buffer enable 2 bufenb2 /gpio7 in/out transfer acknowledge ta/gpio20 transfer acknowledge signal in/out introduction 2-2 mcf5249um motorola serial clock line scl0/qspi_clk clock signal for first i 2 c module operation signal is also qspi clock in/out serial data line sda0/qspi_din serial data port first i 2 c module operation signal is also qspi data in in/out serial clock line scl1_gpio3 clock signal for second i 2 c module operation in/out serial data line sda1_gpio55 serial data port for second i 2 c module operation in/out receive data rxd1/gpi28/adin2 rxd0/gpi27 signal is receive serial data input for duart in transmit data txd1/gpo28 txd0/gpo27 signal is transmit serial data output for duart out asserted request-to-send rts 1/gpo31 rts 2/gpo30 duart signals a ready to receive data query out negated clear-to-send cts 1/adin3/gpi31 cts 0/gpi30 signals to duart that data can be transmitted to peripheral cts 2 is multiplexed with an a/d input in timer input tin0/gpi33 tin1/gpio23 provides clock input to timer or provides trigger to timer value capture logic in in/out timer output tout0/gpo33 tout1/adout/gpo35 capable of output waveform or pulse generation out iec958 inputs ebuin1/gpi36 ebuin2/gpi37 ebuin3/adin0/gpi38 ebuin4/adin1/gpi39 audio interfaces iec958 inputs multiplexed with some a/d inputs in iec958 outputs ebuout1/gpo36 ebuout2/gpo37 audio interfaces iec958 outputs out serial data in sdatai1 sdatai3/gpi41 sdatai4/gpi42 audio interfaces serial data inputs in serial data out sdatao1/gpio25 sdatao2/gpo41 audio interfaces serial data outputs in/out out word clock lrck1 lrck2/gpio44 lrck3/gpio45 lrck4/gpio46 audio interfaces serial word clocks in/out bit clock sclk1 sclk2/gpio48 sclk3/gpio49 sclk4/gpio50 audio interfaces serial bit clocks in/out serial input ef/gpio19 error flag serial in in/out serial input cflg/gpio18 c-flag serial in in/out table 2-1 mcf5249 signal index (continued) signal name mnemonic function input/ output reset state introduction motorola section 2 signal description 2-3 subcode clock rck/gpio51 audio interfaces subcode clock in/out subcode sync sfsy/gpio52 audio interfaces subcode sync in/out subcode data subr/gpio53 audio interfaces subcode data in/out clock frequency trim xtrim/gpo38 clock trim control out audio clocks out mclk1/gpo39 mclk2/gpo42 dac output clocks out memorystick/secure digital interface cmdsdio2/gpio34 secure digital command lane memorystick interface 2 data i/o in/out sclkout/gpio15 clock out for both memorystick interfaces and for secure digital in/out sdata0_sdio1/gpio54 securedigital serial data bit 0 memorystick interface 1 data i/o in/out sdata1_bs1/gpio9 securedigital serial data bit 1 memorystick interface 1 strobe in/out rsto/sdata2_bs2 securedigital serial data bit 2 memorystick interface 2 strobe reset output signal in/out sdata3/gpio56 securedigital serial data bit 3 in/out adc ebuin3/adin0/gpi38 ebuin4/adin1/gpi39 rxd2/adin2/gpi28 cts2/adin3/gpi31 analog to digital converter input signals in/out adc tout1/adout/gpo35 analog to digital convertor output signal in/out qspi clock scl/qspi_clk qspi clock signal in/out qspi data in sda/qspi_din qspi data input in/out qspi data out qspidout/gpio26 qspi data out in/out qspi chip selects qspics0/gpio29 qspics1/gpio24 qspics2/gpio21 qspics3/gpio22 qspi chip selects in/out crystal in crin crystal input in reset in rsti processor reset input in motorola test mode test[3:0] should always be low. in high impedance hiz assertion three-states all output signal pins. in debug data ddata3/gpio4 ddata2/gpio2 ddata1/gpio1 ddata0/gpio0 displays captured processor data and break-point status. in/out hi-z processor status pst3/gpio62 pst2/gpio61 pst1/gpio60 pst0/gpio59 indicates internal processor status. in/out hi-z processor clock pstclk/gpo63 processor clock output out table 2-1 mcf5249 signal index (continued) signal name mnemonic function input/ output reset state gpio 2-4 mcf5249um motorola note: the cmd_sdio2, sdata0_sdio1, rsto/sdata2_bs2, a25, qspi_cs1, qspi_cs3, sdram_cs2, ebuout2, bufenb2, subr, sfsy, rck, sre, lrck3, swe, and the sclk3 signals are only used in the 160 mapbga package. 2.2 gpio many pins have a gpio as first or second function. if gpio is second function, following rules apply: general purpose input is always active, regardless of state of pin. general purpose output or primary output is determined by value written to gpio function select register. power-on reset function is not gpio 2.3 mcf5249 bus signals these signals provide the external bus interface to the mcf5249. 2.3.1 address bus the address bus provides the address of the byte or most significant byte of the word or longword being transferred.the address lines also serve as the dram address pins, providing multiplexed row and column address signals. bits 23 down to 1 and 25 of the address are available. a25 is intended to be used with 256 mbit dram?s. signals are named: a[23:1] a[25]/gpo8 2.3.2 read-write control this signal indicates during any bus cycle whether a read or write is in progress. a low is write cycle and a high is a read cycle. test clock tck clock signal for ieee 1149.1a jtag. in test reset/development serial clock trst /dsclk multiplexed signal that is asynchronous reset for jtag controller. clock input for debug module. in test mode select/ break point tms/bkpt multiplexed signal that is test mode select in jtag mode and a hardware break-point in debug mode. in test data input / development serial input tdi/dsi multiplexed serial input for the jtag or background debug module. in test data output/development serial output tdo/dso multiplexed serial output for the jtag or background debug module. out table 2-1 mcf5249 signal index (continued) signal name mnemonic function input/ output reset state sdram controller signals motorola section 2 signal description 2-5 2.3.3 output enable the oe signal is intended to be connected to the output enable of asynchronous memories connected to chip selects. during bus read cycles, the coldfire processor will drive oe low. 2.3.4 data bus the data bus (d[31:16]) is bi-directional and non-multiplexed. data is registered by the mcf5249 on the rising clock edge. the port width for each chip-select and dram bank are programmable. the data bus uses a default configuration if none of the chip-selects or dram bank match the address decode. all 16 bits of the data bus are driven during writes, regardless of port width or operand size. 2.3.5 transfer acknowledge the ta/gpio20 pin is the transfer acknowledge signal. 2.4 sdram controller signals the following sdram signals provide a seamless interface to external sdram. an sdram width of 16 bits is supported and can access as much as 64 mbytes of memory. adrams are not supported. note: the sdram_cs2 signal is only used on the 160 mapbga package. 2.5 chip selects there are two chip select outputs on the mcf5249 device. cs 0 and cs 1/gpio58. the second signal is multiplexed with a gpio signal. the active low chip selects can be used to access asynchronous memories. the interface is glueless. table 2-2 sdram controller signals sdram signal description synchronous dram row address strobe the sdras active low pin provides a seamless interface to the ras input on synchronous dram synchronous dram column address strobe the sdcas active low pin provides a seamless interface to cas input on synchronous dram. synchronous dram write the sdwe active-low pin is asserted to signify that a sdram write cycle is underway. this pin outputs logic ?1? during read bus cycles. synchronous dram chip enables the sdram_cs1 and sdram_cs 2/gpio7 active-low output signals are used during synchronous mode to route directly to the chip selects of up to 2 sdram devices. the sdram_cs2 /gpio7 can be programmed to be gpio using the gpio-function register. synchronous dram udqm and lqdm signals the dram byte enables udmq and ldqm are driven by the sdudqm and sdldqm byte enable outputs. synchronous dram clock the dram clock is driven by the sclk signal synchronous dram clock enable the bclke active high output signal is used during synchronous mode to route directly to the scke signal of external sdrams. this signal provides the clock enable to the sdram. isa bus 2-6 mcf5249um motorola 2.6 isa bus the mcf5249 supports an isa bus. (no isa dma channel). using the isa bus protocol, reads and writes to up to two isa bus peripherals are possible. for the first peripheral, cs2/ide-dior/ gpio13 and ide-diow /gpio14 are the read and write strobe. for the second peripheral, cs3/sre /gpio11 and swe /gpio12 are the read and write strobe. either peripheral can insert wait states by pulling ide-iordy/gpio16 2.7 bus buffer signals as the mcf5249 has a quite complicated slave bus, with the possibility to put dram on the bus, put asynchronous memories on the bus, and to put isa bus peripherals on the bus, it may become necessary to introduce a bus buffer on the bus. the mcf5249 has a glueless interface to steer these bus buffers with 2 bus buffer output signals bufenb1 /gpio57 and bufenb2 /gpio7. note: the bufenb2 signal is only used in the 160 mapbga package. 2.8 i 2 c module signals there are two i 2 c interfaces on this device. the i 2 c module acts as a quick two-wire, bidirectional serial interface between the mcf5249 processor and peripherals with an i 2 c interface (e.g., led controller, a-to-d converter, d-to-a converter). when devices connected to the i 2 c bus drive the bus, they will either drive logic-0 or high-impedance. this can be accomplished with an open-drain output. 2.9 serial module signals the following signals transfer serial data between the two uart modules and external peripherals. all serial module signals can be used as gp i or gpo. the gpio-funct ion and gpio1-function registers must be programmed to determine pin functions of the inputs and outputs. if used as gpo or gpi, uart functionality is lost. table 2-3 i 2 c module signals i 2 c module signal description i 2 c serial clock the scl/qpsiclk and scl2/gpio3 bidirectional signals are the clock signal for first and second i 2 c module operation. the i 2 c module controls this signal when the bus is in master mode; all i 2 c devices drive this signal to synchronize i 2 c timing. signals are multiplexed function select is done via pllcr register. i 2 c serial data the sda/qspi_din and sda2/gpio55 bidirectional signals are the data input/output for the first and second serial i 2 c interface. signals are multiplexed function select is done via pllcr register. timer module signals motorola section 2 signal description 2-7 2.10 timer module signals the following signals are external interface to the two general-purpose mcf5249 timers. these 16-bit timers can capture timer values, trigger external events, or internal interrupts, or count external events. these pins can be reused as gpo or gpi. regi sters gpio-function and gpio1-function must be programmed for this. 2.11 serial audio interface signals all serial audio interface signals can be programmed to serve as general purpose i/os or as serial audio interface signals. the function is programmed using gpio-function and gp io1-function registers. note: the lrck3 and sclk3 signals are only used in the 160 mapbga package. table 2-4 serial module signals serial module signal description receive data the rxd1_gpi27 and rxd2/adin2/gpi28 are the inputs on which serial data is received by the duart. data is sampled on rxd[1:0] on the rising edge of the serial clock source, with the least significant bit received first. transmit data the duart transmits serial data on the txd1/gpo27 and txd2/gpo28 output signals. data is transmitted on the falling edge of the serial clock source, with the least significant bit transmitted (lsb) first. when no data is being transmitted or the transmitter is disabled, these two signals are held high. txd[1:0] are also held high in local loopback mode. request to send the rts 1/gpo30 and rts 2/gpo31 request-to-send outputs indicate to the peripheral device that the duart is ready to send data and requires a clear-to-send signal to initiate transfer. clear to send peripherals drive the cts 1/gpi30 and cts 2/adin3/gpi31 inputs to indicate to the mcf5249 serial module that it can begin data transmission. table 2-5 timer module signals serial module signal description timer input users can program the tin0/gpi33 and tin1/gpio23 inputs as clocks that cause events in the counter and prescalars. they can also cause capture on the rising edge, falling edge, or both edges. timer output the tout0/gpo33 and tout1/adout/gpo35 programmable outputs pulse or toggle on various timer events. serial audio interface signals 2-8 mcf5249um motorola table 2-6 serial audio interface signals serial module signal description serial audio bit clock the sclk1, sclk2/gpio48, sclk3/gpio49, and sclk4/gpio50 multiplexed pins can serve as general purpose i/os or serial audio bit clocks. as bit clocks, these bidirectional pins can be programmed as outputs to drive their associated serial audio (iis) bit clocks. alternately, these pins can be programmed as inputs when the serial audio bit clocks are driven internally. the functionality is programmed within the audio module. during reset, these pins are configured as input serial audio bit clocks. serial audio word clock the lrck1, lrck2/gpio44, lrck3/gpio45, and lrck4/gpio46 multiplexed pins can serve as general purpose i/os or serial audio word clocks. as word clocks, the bidirectional pins can be programmed as inputs to drive their associated serial audio word clock. alternately, these pins can be programmed as outputs when the serial audio word clocks are derived internally. the functionality is programmed within the audio module. during reset, these pins are configured as input serial audio word clocks. serial audio data in the sdatai1, sdatai3/gpi41, sdatai4/gpi42 multiplexed pins can serve as general purpose i/os or serial audio inputs. as serial audio inputs the data is sent to interfaces 1,3 and 4 respectively. the functionality of these pins is programmed with the gpio-function and gpio1-function registers. during reset, the pins are configured as serial data inputs. serial audio data out the sdatao1/gpio25 and sdatao2/gpi41 multiplexed pins can serve as general purpose i/os or serial audio outputs. the functionality of these pins is programmed with registers gpio-function and gpio1-function. during reset, the pins are configured as serial data outputs. serial audio error flag the ef/gpio19 multiplexed pin can serve as general purpose i/os or error flag input. as error flag input, this pin will input the error flag delivered by the cd-dsp. ef/gpio19 is only relevant for serial interface in 1 serial audio cflg the cflg/gpio18 multiplexed pin can serve as general purpose i/o or cflg input. as cflg input, the pin will input the cflg flag delivered by the cd-dsp. cflg/gpio18 is only relevant for serial interface in 1. digital audio interface signals motorola section 2 signal description 2-9 2.12 digital audio interface signals note: the ebuout2 signal is only used on the 160 mapbga package. 2.13 subcode interface there is a 3-line subcode interface on the mcf5249. this 3-line subcode interface allows the device to format and transmit subcode in eiaj format to a cd channel encoder device. the three signals are described in table 2-8 note: the subr, sfsy, and the rck signals are only used in the 160 mapbga package. 2.14 analog to digital converter (adc) the single output on the tout1/adout/gpo35 pin provides the reference voltage in pdm format therefore this output requires an external integrator circuit (resistor/capacitor) to convert it to a dc level to be used by the external comparator circuit. four external comparators compare the dc level obtained after filtering tout1/adout/gpo35 with the relevant input signals. the outputs of the comparators are fed to the 4 adin inputs on the mcf5249: ebuin3/adin0/gpi38, ebuin4/adin1/gpi39, rxd2/adin2/gpi38 and cts2/adin3/gpi31. table 2-7 digital audio interface signals serial module signal description digital audio in the ebuin1/gpi36, ebuin2/gpi37, ebuin3/adin0/gpi38, and ebuin4/adin1/gpi39 multiplexed signals can serve as general purpose input or can be driven by various digital audio (iec958) input sources. both functionalities are always active. input chosen for iec958 receiver is programmed within the audio module. input value on the 4 pins can always be read from the appropriate gpio register. digital audio out the ebuout1_gpo36 and ebuout2_gpo37 multiplexed pins can serve as general purpose i/o or as digital audio (iec958) output. ebuout1 is digital audio out for consumer mode, ebuout2 is digital audio out for professional mode. the functionality of the pins is programmed with the gpio-function and gpio1-function register. during reset, the pin is configured as a digital audio output. table 2-8 subcode interface signal signal name description rck/gpio51 subcode clock input. when pin is used as subcode clock, this pin is driven by the cd channel encoder. sfsy/gpio52 subcode sync output this signal is driven high if a subcode sync needs to be inserted in the efm stream. subr/gpio53 subcode data output this signal is a subcode data out pin. secure digital/ memorystick card interface 2-10 mcf5249um motorola selection of function for pin tout1/adout/gpo35 is done by writing gpio function select register (determines if function is gpio or not), and differentiation between timer and adout functions is done in the adconfig register. 2.15 secure digital/ me morystick card interface the device has a versatile flash card interface that supports both securedigital and memorystick cards. the interface can either support one securedigital or two memorystick cards. no mixing of card types is possible. table 2-9 gives the pin descriptions. note: the sdata0_sdio1 and rsto/sdata2_bs2 signals are only used in the 160 mapbga package. 2.16 queued serial peripheral interface (qspi) note: the cmd_sdio2 signal is only used in the 160 mapbga package. the qspi interface is a high-speed serial interface allowing transmit and receive of serial data. pin descriptions are given in table 2-10 . table 2-9 flash memory card signals flash memory signal description sclkout/gpio15 clock out for both memorystick interfaces and for securedigital cmd_sdio2/gpio34 secure digital command line memorystick interface 2 data i/o sdata0_sdio1/gpio54 securedigital serial data bit 0 memorystick interface 1 data i/o sdata1_bs1/gpio9 securedigital serial data bit 1 memorystick interface 1 strobe rsto/sdata2_bs2 securedigital serial data bit 2 memorystick interface 2 strobe reset output signal selection between reset function and sdata2_bs2 is done by programming pllcr register. sdata3/gpio57 securedigital serial data bit 3 table 2-10 queued serial peripheral interface (qspi) signals serial module signal description scl_qspiclk multiplexed signal iic interface clock or qspi clock output function select is done via pllcr register. sda_qspidin multiplexed signal iic interface data or qspi data input. function select is done via pllcr register. qspidout_gpio26 qspi data output qspics0_gpio29 4 different qspi chip selects qspics1_gpio24 qspics2_gpio21 qspics3_gpio22 crystal trim motorola section 2 signal description 2-11 2.17 crystal trim the xtrim_gpo38 output produces a pulse-density modulated phase/frequency difference signal to be used after low-pass filtering to control varicap-voltage to control crystal oscillation frequency. this will lock the crystal to the incoming digital audio signal. 2.18 clock out the mclk1/gpo39 and mclk2/gpo42 can serve as general purpose i/os or as dac clock outputs. when programmed as dac clock outputs, these signals are directly divided from the crystal. 2.19 debug and test signals these signals interface with external i/o to provide processor status signals. 2.19.1 test mode the test[3:0] inputs are used for various manufacturing and debug tests. for normal mode these inputs should always be tied low. use test0 to switch between background debug mode and jtag mode. drive test0 high for debug mode. 2.19.2 high impedance the assertion of hi_z will force all output drivers to a high-impedance state. the timing on hi_z is independent of the clock. note: jtag operation will override the hi_z pin. 2.19.3 processor clock output the internal pll generates this pstclk_gpo63 and output signal, and is the processor clock output that is used as the timing reference for the debug bus timing (ddata[3:0] and pst[3:0]). the pstclk_gpo63 is at the same frequency as the core processor and cache memory. the frequency will be twice the bus clock (sclk) frequency. 2.19.4 debug data the debug data pins, ddata0_gpio0, ddata1_gpio1, ddata2_gpio2, and ddata3_gpio4, are four bits wide. this nibble-wide bus displays captured processor data and break-point status. refer to for additional information on this bus. 2.19.5 processor status the processor status pins, pst0_gpio59, pst1_gpio60, pst2_gpio61, and pst3_gpio62, indicate the mcf5249 processor status. during debug mode, the timing is synchronous with the processor clock (pstclk) and the status is not related to the current bus transfer. table 2-11 shows the encodings of these signals. bdm/jtag signals 2-12 mcf5249um motorola . 2.20 bdm/jtag signals the mcf5249 complies with the ieee 1149.1a jtag testing standard. the jtag test pins are multiplexed with background debug pins. 2.20.1 test clock tck is the dedicated jtag test logic clock that is independent of the mcf5249 processor clock. various jtag operations occur on the rising or falling edge of tck. the internal jtag controller logic is designed such that holding tck high or low for an indefinite period of time will not cause the jtag test logic to lose state information. if tck will not be used, it should be tied to ground. 2.20.2 test reset/development serial clock the test[3:0] signals determine the function of the trst /dsclk dual-purpose pin. if test[3:0]=0001, the dsclk function is selected. if test[3:0]= 0000, the trst function is selected. test[3:0] should not be changed while rsti = 1. when used as trst , this pin will asynchronously reset the internal jtag table 2-11 processor status signal encodings pst[3:0] definition (hex) (binary) $0 0000 continue execution $1 0001 begin execution of an instruction $2 0010 reserved $3 0011 entry into user-mode $4 0100 begin execution of pulse and wddata instructions $5 0101 begin execution of taken branch or synch_pc 1 $6 0110 reserved $7 0111 begin execution of rte instruction $8 1000 begin 1-byte data transfer on ddata $9 1001 begin 2-byte data transfer on ddata $a 1010 begin 3-byte data transfer on ddata $b 1011 begin 4-byte data transfer on ddata $c 1100 exception processing 2 $d 1101 emulator mode entry exception processing 2 $e 1110 processor is stopped, waiting for interrupt 2 $f 1111 processor is halted 2 note 1. rev. b enhancement. note 2. these encodings are asserted for multiple cycles. bdm/jtag signals motorola section 2 signal description 2-13 controller to the test logic reset state, causing the jtag instruction register to choose the ?bypass? command. when this occurs, all the jtag logic is benign and will not interfere with the normal functionality of the mcf5249 processor. although this signal is asynchronous, motorola recommends that trst make only a 0 to 1 (asserted to negated) transition while tms is held at a logic 1 value. trst has an internal pullup so that if it is not driven low its value will default to a logic level of 1. however, if trst will not be used, it can either be tied to ground or, if tck is clocked, it can be tied to vdd. if it is tied to ground, it will place the jtag controller in the test logic reset state immediately. if it is tied to vdd, it will cause the jtag controller (if tms is a logic 1) to eventually end up in the test logic reset state after 5 clocks of tck. this pin is also used as the development serial clock (dsclk) for the serial interface to the debug module.the maximum frequency for the dsclk signal is 1/5 the bclko frequency. see for additional information on this signal. 2.20.3 test mode select/break point the test[3:0] signals determine the tms/bkpt pin function. if test[3:0] =0001, the bkpt function is selected. if test[3:0] = 0000, then the tms function is selected. test[3:0] should not change while rsti = 1. when used as tms, this input signal provides the jtag controller with information to determine which test operation mode should be performed. the value of tms and current state of the internal 16-state jtag controller state machine at the rising edge of tck determine whether the jtag controller holds its current state or advances to the next state. this directly controls whether jtag data or instruction operations occur. tms has an internal pullup so that if it is not driven low, its value will default to a logic level of 1. however, if tms will not be used, it should be tied to vdd. this pin also signals a hardware breakpoint to the processor when in the debug mode. see for additional information on this signal. 2.20.4 test data input/development serial input the tdi/ds is a dual-function pin. if test[3:0] = 0001, then dsi is selected. if test[3:0] = 0000, then tdi is selected. when used as tdi, this input signal provides the serial data port for loading the various jtag shift registers composed of the boundary scan register, the bypass register, and the instruction register. shifting in of data depends on the state of the jtag controller state machine and the instruction currently in the instruction register. this data shift occurs on the rising edge of tck. tdi also has an internal pullup so that if it is not driven low its value will default to a logic level of 1. however, if tdi will not be used, it should be tied to vdd. this pin also provides the single-bit communication for the debug module commands. see for additional information on this signal. 2.20.5 test data output/development serial output the tdo/dso is a dual-function pin. when test[3:0] = 0001, then dso is selected. when test[3:0] = 0000, tdo is selected. when used as tdo, this output signal provides the serial data port for outputting data from the jtag logic. shifting out of data depends on the state of the jtag controller state machine and the instruction currently in the instruction register. this data shift occurs on the falling edge of tck. when tdo is not outputting test data, it is three-stated. tdo can also be placed in three-state mode to allow bussed or parallel connections to other devices having jtag. this signal also provides single-bit communication for the debug module responses. see for additional information on this signal. clock and reset signals 2-14 mcf5249um motorola 2.21 clock and reset signals these signals configure the mcf5249 and provide interface signals to the external system. 2.21.1 reset in asserting rsti causes the mcf5249 to enter reset exception processing. when rsti is recognized, the data bus is tri-stated. 2.21.2 system bus input the crin signal is the system clock input. the device has no on-chip clock oscillator, and needs an external oscillator. motorola section 3 coldfire core 3-1 section 3 coldfire core this section provides an overview of the microprocessor core of the mcf5249. the section describes the v2 programming model as it is implemented on the mcf5249. it also includes a full description of exception handling, data formats, an instruction set summary, and a table of instruction timings. for detailed information on instructions, see the coldfire family programmer?s reference manual . 3.1 processor pipelines the following figure shows a block diagram of the processor pipelines of a v2 coldfire core . figure 3-1 v2 coldfire processor core pipelines the processor core is comprised of two separate pipelines that are decoupled by an instruction buffer. the instruction fetch pipeline (ifp) is responsible for instruction address generation and instruction fetch. the instruction buffer is a first-in-first-out (fifo) buffer that holds prefetched instructions awaiting execution in the operand execution pipeline (oep). the oep includes two pipeline stages. the first stage decodes instructions and selects operands (dsoc); the second stage (agex) performs instruction execution and calculates operand effective addresses, if needed. fifo instruction buffer decode & select, operand fetch address generation, execute ifp oep address[31:0] data[31:0] 3 x 32 instruction fetch pipeline operand execution pipeline instruction fetch instruction address ia generation 3-2 mcf5249um motorola processor register description 3.2 processor register description the following sections describe the processor registers in the user and supervisor programming models. the appropriate programming model is selected based on the privilege level (user mode or supervisor mode) of the processor as defined by the s bit of the status register. 3.2.1 user programming model figure shows the user programming model. the model is the same as the m68000 family of microprocessors and consists of the following registers: 16 general-purpose 32-bit registers (d0?d7, a0?a7) 32-bit program counter (pc) 8-bit condition code register (ccr) 3.2.1.1 data registers (d0?d7) registers d0?d7 are used as data registers for bit (1 bit), byte (8 bit), word (16 bit) and longword (32 bit) operations and can also be used as index registers. 3.2.1.2 address registers (a0?a6) registers a0?a6 can be used as software stack pointers, index registers, or base address registers as well as for word and longword operations. 3.2.1.3 stack pointer (a7,sp) the coldfire architecture supports a single hardware stack pointer (a7) for explicit references as well as for implicit ones during stacking for subroutine calls and returns and exception handling. the initial value of a7 is loaded from the reset exception vector, address $0. the same register is used for both user and supervisor mode as well as word and longword operations. processor register description motorola section 3 coldfire core 3-3 figure 3-2 user programming model a subroutine call saves the program counter (pc) on the stack and the return restores it from the stack. both the pc and the status register (sr) are saved to the stack during the processing of exceptions and interrupts. the return from exception instruction restores the sr and pc values from the stack. 3.2.1.4 program counter (pc) the pc contains the address of the next instruction to execute. during instruction execution and exception processing, the processor automatically increments the contents of the pc or places a new value in the pc, as appropriate. for some addressing modes, the pc can be used as a pointer for pc-relative operand addressing. 3.2.1.5 condition code register (ccr) the ccr is the least significant byte of the processor status register (sr). refer to status register (sr) on page 3-6 for more information. bits 4?0 represent indicator flags based on results generated by processor operations. bit 4, the extend bit (x bit), is also used as an input operand during multiprecision arithmetic computations. table 3-1 condition code register (bits 0-4) 76543210 ??? x n z v c d0 d1 d2 d3 d4 d5 d6 d7 a0 a1 a2 a3 a4 a5 a6 a7 ccr pc 15 7 0 15 0 31 data registers address registers stack pointer program counter condition code register 7 3-4 mcf5249um motorola processor register description the following table describes the bits in the condition code register. 3.2.2 enhanced multiply accumul ate module (emac) user programming model the emac provides a variety of program-visible registers: four 48-bit accumulators (raccx = racc0, racc1, racc2, racc3) eight 8-bit accumulator extensions (2 per accumulator), packaged as two 32-bit values for load and store operations (raccext01, raccext23) one 16-bit mask register (rmask) one 32-bit status register (macsr) including four indicator bits signaling product or accumulation overflow (one for each accumulator: pav0, pav1, pav2, pav3) 3.2.2.1 emac instruction set summary the emac unit supports the integer multiply operations defined by the baseline coldfire architecture, as well as the multiply-accumulate instructions. the following table summarizes the emac unit instruction set. table 3-2 ccr functionality bit code description 7?5 ? reserved, should be cleared. 4 x extend condition code bit. assigned the value of the carry bit for arithmetic operations; otherwise not affected or set to a specified result. also used as an input operand for multiple-precision arithmetic. 3 n negative condition code bit. set if the msb of the result is set; otherwise cleared. 2 z zero condition code bit. set if the result equals zero; otherwise cleared. 1 v overflow condition code bit. set if an arithmetic overflow occurs, implying that the result cannot be represented in the operand size; otherwise cleared. 0 c carry condition code bit. set if a carry-out of the data operand msb occurs for an addition or if a borrow occurs in a subtraction; otherwise cleared. table 3-3 emac instruction summary command mnemonic description multiply signed muls processor register description motorola section 3 coldfire core 3-5 3.2.3 supervisor programming model only system programmers use the supervisor programming model to implement sensitive operating system functions, i/o control, and memory management. all accesses that affect the control features of coldfire processors are in the supervisor programming model, which consists of the registers available to users as well as the following control registers: 16-bit status register (sr) 32-bit vector base register (vbr) additional registers may be supported on a part-by-part basis. the following sections describe the supervisor programming model registers. load mac status reg mov.l {ry,#imm},macsr writes a value to the mac status register store mac status reg mov.l macsr,rx write the contents of the mac status register to a cpu register store macsr to ccr mov.l macsr,ccr write the contents of the mac status register to the processor?s ccr register load mac mask reg mov.l {ry,#imm},rmask writes a value to the mac mask register store mac mask reg mov.l rmask,rx writes the contents of the mac mask register to a cpu register load accextensions01 mov.l {ry,#imm},raccext01 loads the accumulator 0,1 extension bytes with a 32-bit operand load accextensions23 mov.l {ry,#imm},raccext23 loads the accumulator 2,3 extension bytes with a 32-bit operand store accextensions01 mov.l raccext01,rx writes the contents of accumulator 0,1 extension bytes into a cpu register store accextensions23 mov.l raccext23,rx writes the contents of accumulator 2,3 extension bytes into a cpu register 31 ? 20 19 ? 0 must be zeros vbr vector base register 15 ? 8 7 ? 0 system byte ccr sr status register figure 3-3 supervisor programming model table 3-3 emac instruction summary command mnemonic description 3-6 mcf5249um motorola processor register description 3.2.3.1 status register (sr) the sr stores the processor status and includes the ccr, the interrupt priority mask, and other control bits. in the supervisor mode, software can access the entire sr. in user mode, only the lower 8 bits are accessible (ccr). the control bits indicate the following states for the processor: trace mode (t-bit), supervisor or user mode (s bit), and master or interrupt state (m). 3.2.3.2 vector base register (vbr) the vbr contains the base address of the exception vector table in memory. the displacement of an exception vector is added to the value in this register to access the vector table. the lower 20 bits of the vbr are not implemented by coldfire processors; they are zero, forcing the table to be aligned on a 1 mbyte boundary. table 3-4 status register system byte condition code register (ccr) 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 t 0 s m 0 i[2:0] 0 0 0 x n z v c table 3-5 status bit descriptions bit name description t when set, the trace enable allows the processor to perform a trace exception after every instruction. s the supervisor / user state bit denotes whether the processor is in supervisor mode (s=1) or user mode (s=0). m the master / interrupt state bit is cleared by an interrupt exception, and can be set by software during execution of the rte or move to sr instructions. i [2:0] the interrupt priority mask defines the current interrupt priority. interrupt requests are inhibited for all priority levels less than or equal to the current priority, except the edge-sensitive level 7 request, which cannot be masked. 30 ? 21 19 ? 0 field exception vector table base address ? reset 0000_0000_0000_0000_0000_0000_0000_0000 r/w written from a bdm serial command or from the cpu using the movec instruction. vbr can be read from the debug module only. the upper 12 bits are returned, the low-order 20 bits are undefined. rc [11-0] 0x801 figure 3-4 vector base register (vbr) exception processing overview motorola section 3 coldfire core 3-7 3.3 exception processing overview exception processing for coldfire processors is streamlined for performance. the coldfire processors provide a simplified exception processing model. the next section details the model.differences from previous 68000 family processors include: a simplified exception vector table reduced relocation capabilities using the vector base register a single exception stack frame format use of a single self-aligning system stack coldfire processors use an instruction restart exception model but do require more software support to recover from certain access errors. refer to for details. exception processing is comprised of four major steps and is defined as the time from the detection of the fault condition to the fetch of the first handler instruction has been initiated. 1. the processor makes an internal copy of the sr and then enters supervisor mode by setting the s bit and disabling trace mode by clearing the t bit. the occurrence of an interrupt exception also forces the m bit to be cleared and the interrupt priority mask to be set to the level of the current interrupt request. 2. the processor determines the exception vector number. for all faults except interrupts, the processor performs this calculation based on the exception type. for interrupts, the processor performs an interrupt-acknowledge (iack) bus cycle to obtain the vector number from a peripheral device. the iack cycle is mapped to a special acknowledge address space with the interrupt level encoded in the address. 3. the processor saves the current context by creating an exception stack frame on the system stack. the v2 core supports a single stack pointer in the a7 address register; therefore, there is no notion of separate supervisor or user stack pointers. as a result, the exception stack frame is created at a 0-modulo-4 address on the top of the current system stack. additionally, the processor uses a simplified fixed-length stack frame for all exceptions. the exception type determines whether the program counter placed in the exception stack frame defines the location of the faulting instruction (fault) or the address of the next instruction to be executed (next). 4. the processor calculates the address of the first instruction of the exception handler. by definition, the exception vector table is aligned on a 1 mbyte boundary. this instruction address is generated by fetching an exception vector from the table located at the address defined in the vector base register. the index into the exception table is calculated as (4 x vector number). once the exception vector has been fetched, the contents of the vector determine the address of the first instruction of the desired handler. after the instruction fetch for the first opcode of the handler has been initiated, exception processing terminates and normal instruction processing continues in the handler. coldfire 5200 processors support a 1024-byte vector table aligned on any 1 mbyte address boundary (see table 3-6 ). the table contains 256 exception vectors where the first 64 are defined by motorola and the remaining 192 are user-defined interrupt vectors. the v2 core processor inhibits sampling for interrupts during the first instruction of all exception handlers. this allows any handler to effectively disable interrupts, if necessary, by raising the interrupt mask level contained in the status register. 3-8 mcf5249um motorola exception stack frame definition 3.4 exception stack frame definition the exception stack frame is shown in figure . the first longword of the exception stack frame contains the 16-bit format/vector word (f/v) and the 16-bit status register, and the second longword contains the 32-bit program counter address. table 3-6 exception vector assignments vector number(s) vector offset (hex) stacked program counter assignment 0 $000 ? initial stack pointer 1 $004 ? initial program counter 2 $008 fault access error 3 $00c fault address error 4 $010 fault illegal instruction 5 $014 fault divide by zero 6-7 $018-$01c ? reserved 8 $020 fault privilege violation 9 $024 next trace 10 $028 fault unimplemented line-a opcode 11 $02c fault unimplemented line-f opcode 12 $030 next debug interrupt 13 $034 ? reserved 14 $038 fault format error 15 $03c next uninitialized interrupt 16-23 $040-$05c ? reserved 24 $060 next spurious interrupt 25-31 $064-$07c next level 1-7 autovectored interrupts 32-47 $080-$0bc next trap # 0-15 instructions 48-63 $0c0-$0fc ? reserved 64-255 $100-$3fc next user-defined interrupts note: ?fault? refers to the pc of the instruction that caused the exception note: ?next? refers to the pc of the next instruction that follows the instruction that caused the fault. exception stack frame definition motorola section 3 coldfire core 3-9 figure 3-5 exception stack frame form the 16-bit format/vector word contains 3 unique fields: a 4-bit format field at the top of the system stack is always written with a value of {4,5,6,7} by the processor indicating a two-longword frame format. see table 3-7 . there is a 4-bit fault status field, fs[3:0], at the top of the system stack. this field is defined for access and address errors only and written as zeros for all other types of exceptions. see table 3-8 . the 8-bit vector number, vector[7:0], defines the exception type and is calculated by the processor for all internal faults and represents the value supplied by the peripheral in the case of an interrupt. refer to table 3-6 . table 3-7 format field encoding original a7 @ time of exception, bits 1:0 a7 @ 1st instruction of handler format field 00 original a7 - 8 4 01 original a7 - 9 5 10 original a7 - 10 6 11 original a7 - 11 7 table 3-8 fault status encoding fs[3:0] definition 00xx reserved 0100 error on instruction fetch 0101 reserved 011x reserved 1000 error on operand write 1001 attempted write to write-protected space 101x reserved 1100 error on operand read 1101 reserved 111x reserved format fs[3:0] vector[7:0] fs[1:0] program counter[31:0] a7 + $04 status register 31 27 25 17 15 c 3-10 mcf5249um motorola processor exceptions 3.5 processor exceptions 3.5.1 access error exception the exact processor response to an access error depends on the type of memory reference being performed. for an instruction fetch, the processor postpones the error reporting until the faulted reference is needed by an instruction for execution. therefore, faults that occur during instruction prefetches that are then followed by a change of instruction flow do not generate an exception. when the processor attempts to execute an instruction with a faulted opword and/or extension words, the access error is signaled and the instruction aborted. for this type of exception, the programming model has not been altered by the instruction generating the access error. if the access error occurs on an operand read, the processor immediately aborts the current instruction?s execution and initiates exception processing. in this situation, any address register updates attributable to the auto-addressing modes, (e.g., (an)+,-(an)), have already been performed, so the programming model contains the updated an value. in addition, if an access error occurs during the execution of a movem instruction loading from memory, any registers already updated before the fault occurs contains the operands from memory. the coldfire processor uses an imprecise reporting mechanism for access errors on operand writes. because the actual write cycle may be decoupled from the processor?s issuing of the operation, the signaling of an access error appears to be decoupled from the instruction that generated the write. accordingly, the pc contained in the exception stack frame merely represents the location in the program when the access error was signaled. all programming model updates associated with the write instruction are completed. the nop instruction can collect access errors for writes. this instruction delays its execution until all previous operations, including all pending write operations, are complete. if any previous write terminates with an access error, it is guaranteed to be reported on the nop instruction. 3.5.2 address error exception any attempted execution transferring control to an odd instruction address (i.e., if bit 0 of the target address is set) results in an address error exception. any attempted use of a word-sized index register (xn.w) or a scale factor of 8 on an indexed effective addressing mode generates an address error as does an attempted execution of a full-format indexed addressing mode. 3.5.3 illegal inst ruction exception the mcf5249 processors decode the full 16-bit opcode and generate this exception if execution of an unsupported instruction is attempted. additionally, attempting to execute an illegal line a or line f opcode generates unique exception types: vectors 10 and 11, respectively. coldfire processors do not provide illegal instruction detection on extension words of any instruction, including movec. attempting to execute an instruction with an illegal extension word causes undefined results. 3.5.4 divide by zero attempted division by zero causes an exception (vector 5, offset = 0x014) except when the pc points to the faulting instruction (divu, divs, remu, rems). processor exceptions motorola section 3 coldfire core 3-11 3.5.5 privilege violation the attempted execution of a supervisor mode instruction while in user mode generates a privilege violation exception. refer to the coldfire programmer?s reference manual for lists of supervisor- and user-mode instructions. 3.5.6 trace exception to aid in program development, the v2 processors provide an instruction-by-instruction tracing capability. while in trace mode, indicated by the assertion of the t bit in the status register (sr[15] = 1), the completion of an instruction execution signals a trace exception. this functionality allows a debugger to monitor program execution. the single exception to this definition is the stop instruction. when the stop opcode is executed, the processor core waits until an unmasked interrupt request is asserted, then aborts the pipeline and initiates interrupt exception processing. because coldfire processors do not support hardware stacking of multiple exceptions, it is the responsibility of the operating system to check for trace mode after processing other exception types. for example, consider the execution of a trap instruction while in trace mode. the processor will initiate the trap exception and then pass control to the corresponding handler. if the system requires that a trace exception be processed, it is the responsibility of the trap exception handler to check for this condition (sr[15] in the exception stack frame asserted) and pass control to the trace handler before returning from the original exception. 3.5.7 debug interrupt this special type of program interrupt is covered in detail in . this exception is generated in response to a hardware breakpoint register trigger. the processor does not generate an iack cycle but rather calculates the vector number internally (vector number 12). 3.5.8 rte and format error exceptions when an rte instruction is executed, the processor first examines the 4-bit format field to validate the frame type. for a coldfire 5200 processor, any attempted execution of an rte where the format is not equal to {4,5,6,7} generates a format error. the exception stack frame for the format error is created without disturbing the original rte frame and the stacked pc pointing to the rte instruction. the selection of the format value provides some limited debug support for porting code from 68000 applications. on 680x0 family processors, the sr was located at the top of the stack. on those processors, bit[30] of the longword addressed by the system stack pointer is typically zero. thus, if an rte is attempted using this ?old? format, it generates a format error on a coldfire 5200 processor. if the format field defines a valid type, the processor: (1) reloads the sr operand, (2) fetches the second longword operand, (3) adjusts the stack pointer by adding the format value to the auto-incremented address after the fetch of the first longword, and then (4) transfers control to the instruction address defined by the second longword operand within the stack frame. 3-12 mcf5249um motorola instruction execution timing 3.5.9 trap instruction exceptions executing trap always forces an exception and is useful for implementing system calls. the trap instruction may be used to change from user to supervisor mode. 3.5.10 interrupt exception the interrupt exception processing, with interrupt recognition and vector fetching, includes uninitialized and spurious interrupts as well as those where the requesting device supplies the 8-bit interrupt vector. autovectoring may optionally be supported through the system integration module (sim). 3.5.11 fault-on-fault halt if a v2 processor encounters any type of fault during the exception processing of another fault, the processor immediately halts execution with the catastrophic ?fault-on-fault? condition. a reset is required to force the processor to exit this halted state. 3.5.12 reset exception asserting the reset input signal to the processor causes a reset exception. the reset exception has the highest priority of any exception; it provides for system initialization and recovery from catastrophic failure. reset also aborts any processing in progress when the reset input is recognized. processing cannot be recovered. the reset exception places the processor in the supervisor mode by setting the s bit and disables tracing by clearing the t bit in the sr. this exception also clears the m bit and sets the processor?s interrupt priority mask in the sr to the highest level (level 7). next, the vbr is initialized to zero ($00000000). the control registers specifying the operation of any memories (e.g., cache and/or ram modules) connected directly to the processor are disabled. note: other implementation-specific supervisor registers are also affected. refer to each of the modules in this manual for details on these registers. after reset is negated, the core performs two longword read bus cycles. the first longword at address 0 is loaded into the stack pointer and the second longword at address 4 is loaded into the program counter. after the initial instruction is fetched from memory, program execution begins at the address in the pc. if an access error or address error occurs before the first instruction is executed, the processor enters the fault-on-fault halted state. 3.6 instruction exe cution timing this section describes v2 processor instruction execution times in terms of processor core clock cycles. the number of operand references for each instruction is enclosed in parentheses following the number of clock cycles. each timing entry is presented as c(r/w) where: c ? number of processor clock cycles, including all applicable operand fetches and writes, and all internal core cycles required to complete the instruction execution. r/w ? number of operand reads (r) and writes (w) required by the instruction. an operation performing a read-modify-write function is denoted as (1/1). this section includes the assumptions concerning the timing values and the execution time details. instruction execution timing motorola section 3 coldfire core 3-13 3.6.1 timing assumptions for the timing data presented in this section, the following assumptions apply: 1. the operand execution pipeline (oep) is loaded with the opword and all required extension words at the beginning of each instruction execution. this implies that the oep does not wait for the instruction fetch pipeline (ifp) to supply opwords and/or extension words. 2. the oep does not experience any sequence-related pipeline stalls. for coldfire 5200 processors, the most common example of this type of stall involves consecutive store operations, excluding the movem instruction. for all store operations (except movem), certain hardware resources within the processor are marked as ?busy? for two clock cycles after the final dsoc cycle of the store instruction. if a subsequent store instruction is encountered within this 2-cycle window, it will be stalled until the resource again becomes available. thus, the maximum pipeline stall involving consecutive store operations is 2 cycles. the movem instruction uses a different set of resources and this stall does not apply. 3. the oep completes all memory accesses without any stall conditions caused by the memory itself. thus, the timing details provided in this section assume that an infinite zero-wait state memory is attached to the processor core. 4. all operand data accesses are aligned on the same byte boundary as the operand size, i.e., 16 bit operands aligned on 0-modulo-2 addresses, 32 bit operands aligned on 0-modulo-4 addresses. if the operand alignment fails these guidelines, it is misaligned. the processor core decomposes the misaligned operand reference into a series of aligned accesses as shown in the following table. 3.6.2 move instruction execution times the execution times for the move.{b,w} instructions are shown in table 3-10 , while table 3-11 provides the timing for move.l. note: for all tables in this section, the execution time of any instruction using the pc-relative effective addressing modes is the same for the comparable an-relative mode. table 3-9 misaligned operand references address[1:0] size kbus operations additional c(r/w) x1 word byte, byte 2(1/0) if read 1(0/1) if write x1 long byte, word, byte 3(2/0) if read 2(0/2) if write 10 long word, word 2(1/0) if read 1(0/1) if write 3-14 mcf5249um motorola instruction execution timing the nomenclature ?xxx.wl? refers to both forms of absolute addressing, xxx.w and xxx.l. table 3-10 move byte and word execution times source destination rx (ax) (ax)+ -(ax) (d 16 ,ax) (d 8 ,ax,xi) (xxx).wl dn 1(0/0) 1(0/1) 1(0/1) 1(0/1) 1(0/1) 2(0/1) 1(0/1) an 1(0/0) 1(0/1) 1(0/1) 1(0/1) 1(0/1) 2(0/1) 1(0/1) (an) 3(1/0) 3(1/1) 3(1/1) 3(1/1) 3(1/1) 4(1/1) 3(1/1) (an)+ 3(1/0) 3(1/1) 3(1/1) 3(1/1) 3(1/1) 4(1/1) 3(1/1) -(an) 3(1/0) 3(1/1) 3(1/1) 3(1/1) 3(1/1) 4(1/1) 3(1/1) (d 16 ,an) 3(1/0) 3(1/1) 3(1/1) 3(1/1) 3(1/1) ? ? (d 8 ,an,xi) 4(1/0) 4(1/1) 4(1/1) 4(1/1) ? ? ? (xxx).w 3(1/0) 3(1/1) 3(1/1) 3(1/1) ? ? ? (xxx).l 3(1/0) 3(1/1) 3(1/1) 3(1/1) ? ? ? (d 16 ,pc) 3(1/0) 3(1/1) 3(1/1) 3(1/1) 3(1/1) ? ? (d 8 ,pc,xi) 4(1/0) 4(1/1) 4(1/1) 4(1/1) ? ? ? # standard one operand instruction execution times motorola section 3 coldfire core 3-15 3.7 standard one operand instruction execution times table 3-12 one operand instruction execution times opcode 3-16 mcf5249um motorola standard two operand instruction execution times 3.8 standard two operand instruction execution times table 3-13 two operand instruction execution times - (macs) opcod e standard two operand instruction execution times motorola section 3 coldfire core 3-17 msac.l ry,rx 3(0/0) ? ? ? ? ? ? ? mac.w ry,rx,ea,r w ? 2(1/0) 2(1/0) 2(1/0) 2(1/0) ? ? ? mac.l ry,rx,ea,r w ? 2(1/0) 2(1/0) 2(1/0) 2(1/0) ? ? ? msac.w ry,rx,ea,r w ? 2(1/0) 2(1/0) 2(1/0) 2(1/0) ? ? ? msac.l ry,rx,ea,r w ? 2(1/0) 2(1/0) 2(1/0) 2(1/0) ? ? ? moveq #imm,dx ? ? ? ? ? ? ? 1(0/0) muls.w 3-18 mcf5249um motorola miscellaneous instruction execution times 3.9 miscellaneous instruction execution times table 3-14 miscellaneous instruction execution times opcod e branch instruction execution times motorola section 3 coldfire core 3-19 3.10 branch instruction execution times table 3-15 general branch instruction execution times opcode 3-20 mcf5249um motorola notes motorola section 4 phase-locked loop and clock dividers 4-1 section 4 phase-locked loop and clock dividers 4.1 pll features the pll locks to the crystal clock frequency at the crin pin and produces a processor clock (pstclk) and a bus clock which is always 1/2 of the processor clock. the audio clock (audioclk) is derived directly from the crystal. the dac clocks mclk1 and mclk2 are divided directly from the crystal. the pll is configured by writing to a configuration register. by programming this register, the user may change the processor clock (pstclk) and the audio clock (audioclk). the pll configuration register must always be programmed to bypass mode before it is reprogrammed to change any clock frequency. in bypass mode, the crystal clock is fed to the processor (pstclk). when the clock circuit is switched from ?bypass? to ?normal operation?, the switch-over is delayed until the pll is locked. the following figure shows the pll module and the frequency relationships of various clock signals. figure 4-1 phase-locked loop module block diagram divide by cpudiv vco phase frequency comparator divide by vcodiv + divide by 2 divide by 3 divide by 2 0 1 0 1 pllbypass pstcl k sclk mclk1 audioclk mclk2 audiosel crsel,clsel x-tal divide by 4 external circuitry divide by vcoou divide by plldiv + 2 divide by 2 4-2 mcf5249um motorola pll programming 4.2 pll programming the different settings for the pll/clock module are summarized in table 4-1 . note: bits marked n/a are reserved bits; program these bits to 0. table 4-1 pllcr register bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field lock clsel n/a cpudiv crsel audio sel debug sel vcodiv rese t 000000 0 0 0 0 0 0000 0 r/w r r/w bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field vcodiv qspi sel rst sel pll power down plldiv vcoout n/a pll bypass rese t 000000 0 0 0 0 0 0000 0 r/w r/w addr address mbar2bas + 0 x 180 table 4-2 pllcr bit descriptions bit name description lock read-only bit, 1 if pll is locked. (see note 2 following these bit descriptions.) clsel (see note 12) mclk1,mclk2 select bit. cpudiv (see notes 8 and 9) cpu clock divider crsel (see note 3) 0 = fin = fxtal 1 = fin = fxtal/2 audiosel (see note 4) 1 = fxtal 0 = fxtal/2 debugsel (see note 11) 1 = secondary functions on aux debug port. 0 = aux debug port active. vcodiv (see notes 5 and 10) pll compare frequency is vco frequency divided by (vcodiv + 2) qspisel (see note 7) 0 = qspi functions active on pins. (qspi_clk, qspi_din) 1 = iic functions active on pins. (scl, sda) vcoout (see note 6) vco output divider pllbypass (see notes 1 and 2 following these bit descriptions) 1 = switch to pll after pll is locked 0 = bypass pll and dividers rstsel (see note 7) 1 = sdata2bs2 function active on pin 0 = rst function active on pin pll programming motorola section 4 phase-locked loop and clock dividers 4-3 plldiv (see note 5) input frequency (fin) is divided by (plldiv + 2) to determine the pll compare frequency. note: 1. if this bit is written 0, the pll is not used, and the crystal clock is sent directly to the cpu. write this bit 0 bef ore changing any other bit in this register. write back to 1 after writing new settings. after writing 1 to this bit, new setting will become active after a hardware controlled del ay. this delay is ca. 0. 5 ms. clock frequencies described in other notes are only valid when this bit is set 1. note: 2. pll may require up to 10.0 ms to lock note: 3. fin is input frequency to pll. nominal setting for crsel is ?1? for 33.8688 mhz x-tal, ?0? for 16.9344 mhz x-tal. note: 4. audioclk is clock for audio interfaces. may be 11.2896mhz, 16.9344 or 33.8688 mhz. note: 5. fvco = fin * (vcodiv + 2)/ (plldiv + 2) note: 6. fvcoout depends on fvco (note 5) and vcoout setting as shown in the following table: note: 7. this bit selects between two different functions implemented on an external pin. note: 8. fcpu = fvcoout / cpudiv; fcpu is the frequency the processor is running at. note: 9. if field is ?000?, divide by 8 note: 10. fvco max. is 400 mhz note: 11. this bit selects the function of the aux_dsi/ intmon1, aux_bkpt_b/ta, aux_dsclk/intmon2, and aux-dso/a27 pins. if this bit = 0, the primary function (aux_dsi,aux_bkpt_b,aux_dsclk, and aux_dso) is selected. if this bit = 1, the secondary function (intmon1, ta,intmon2, and a27) is selected. note: 12. this field determines the frequency of the dac clocks. fxtal/3 and fxtal/4 should not be used normally: table 4-2 pllcr bit descriptions bit name description vco out setting fvco out 0 fvco 1 fvco/2 2 fvco/2 3 fvco/4 crsel clsel frequency mclk2 frequency mclk1 1 000 fxtal fxtal/2 1 001 fxtal fxtal 1 010 fxtal/2 fxtal/2 1 011 fxtal/2 fxtal 1 100 fxtal fxtal/2 1 101 fxtal fxtal 1 110 fxtal/2 fxtal/2 1 111 fxtal/2 fxtal 0 000 fxtal/2 fxtal/2 0 001 fxtal/2 fxtal/3 0 010 fxtal/2 fxtal/4 0 011 fxtal/3 fxtal/2 0 100 fxtal/3 fxtal/3 0 101 fxtal/3 fxtal/4 0 110 fxtal/4 fxtal/2 0 111 fxtal/4 fxtal/3 4-4 mcf5249um motorola pll programming 4.2.1 pll operation the input to the pll is either the crystal clock, or the crystal clock divided by two. selection is done by crsel. the pll divides this input frequency by a programmable division factor (plldiv+2) . in the pll phase/frequency detector, this divided clock is compared with the vco output clock divided by (vcodiv+2) . as a result, fvco = fin * (vcodiv+2)/(plldiv+2). note: the pll lock counter is designed for worst case input frequency (fin) of 33.8688mhz. this will result in the required 0.5 ns for the pll to lock. other fin frequencies can be used, however, the resulting lock time will be slightly longer. in a second step, this vco clock is divided by (vcoout * cpudiv) to create the cpu clock pstclk. the pll has a pll-bypass feature. when pll bypass is written 0, the crystal clock is passed directly to the cpu. when pll bypass is written 1, cpu clock will be switched to pll-generated values. the switching is delayed until the pll has been locked, and produces a stable clock output for cpu. the processor can read the pll lock status (bit 31 of pllcr). the multiplexers that switch between pll clock and crystal clock is glitch-free, so no system reset is needed after switching this mux. note: it is important that before reprogramming the pll division factors, users must switch to pll bypass mode. after reprogramming, users may immediately switch back to pll enabled mode. switching back is delayed internally until the pll is locked. 4.2.2 pll lock-in time pll lock-in time is less than 10.0 ms. 4.2.3 pll electrical limits due to implementation of the block, some limits apply to the pll block. these limitations are shown in table 4-3 . table 4-3 pll electrical limits name min. frequency mhz max frequency mhz reason notes fvco 200 400 pll limitations fcpu 0 120 (144qfp) 140 (160 mapbga) max. operating frequency of device fin 5 50 pll limitations audio clock generation motorola section 4 phase-locked loop and clock dividers 4-5 4.3 audio clock generation the audio clocks and output dac clocks are divided directly from the crystal. clock settings depend on crsel, clsel, and audiosel bits, as explained in table 4-4 . as the table shows, the audioclk is completely derived from the audiosel bit, and this clock is independent of the other select bits. for the dac clocks (mclk2 and mclk1) the relationship between crsel and clsel is defined in table 4-4 . note: mclk1 and mclk2 will output a clock signal just after reset and before they can be configured as gpio if so desired. the frequency of the clock will be the same as crin prior to initialization of the pll. the multiplexer that switches audioclk between fxtal and fxtal/2 is glitch free. no reset is needed after switching audio clock. for the mclk1 and mclk2 clocks, the divide by 2 is 50% duty cycle, divide by 3 is 33% duty cycle, and divide by 4 is 25% duty cycle. table 4-4 pllcr bit fields pllcr clsel (bits30-28) pllcr crsel (bit 23) pllcr config audiosel (bit 22) audioclk mclk2 mclk1 000 1 1 fxtal fxtal fxtal/2 001 1 1 fxtal fxtal fxtal 010 1 1 fxtal fxtal/2 fxtal/2 011 1 1 fxtal fxtal/2 fxtal 100 1 1 fxtal fxtal fxtal/2 101 1 1 fxtal fxtal fxtal 110 1 1 fxtal fxtal/2 fxtal/2 111 1 1 fxtal fxtal/2 fxtal 000 1 0 fxtal/2 fxtal fxtal/2 001 1 0 fxtal/2 fxtal fxtal 010 1 0 fxtal/2 fxtal/2 fxtal/2 011 1 0 fxtal/2 fxtal/2 fxtal 100 1 0 fxtal/2 fxtal fxtal/2 101 1 0 fxtal/2 fxtal fxtal 110 1 0 fxtal/2 fxtal/2 fxtal/2 111 1 0 fxtal/2 fxtal/2 fxtal 4-6 mcf5249um motorola reduced power mode 4.4 reduced power mode to save power, it is recommended that users reduce the frequency of the cpu clocks. this is done by reprogramming the pllcr register. the pll is also configured with a power down bit. this bit, when set to ?1?, allows the pll to enter ?sleep? mode. in ?sleep? mode, the vco and charge pump are turned off. note: the pll must go through the re-locking procedure when it is re-enabled. 4.5 recommended settings many valid pll settings exist. however, in many cases some limitations apply so that only a few typical settings will be used. in a typical system, the following limitations may exist: users want to run the processor at 120, 96, 64, 84, or 72 mhz clock frequency mclk2 must be one of the following: 16.9344, 11.2896, or 8.4672 mhz see table 4-4 on page 5 in this section for further definition. mclk1 must be one of the following: 16.9344, 11.2896, or 8.4672 mhz see table 4-4 on page 5 in this section for further definition. as a result of these limitations, users may select a 33.8688 mhz x-tal and use the settings shown in table 4-5 . a utility that calculates pll frequencies from pll register settings is available at the following url: http://e-www.motorola.com/webapp/sps/library/prod_lib.jsp (select 32-bit embedded processors, 68k/coldfire, coldfire mc5xxx, mcf5249). table 4-5 recommended pll settings x-tal freq mhz cpu div crsel vco div pll div vco out cpu clock mhz 33.8688 4 1 0x1ad 0x11 0 96 33.8688 6 1 0x1ad 0x011 0 64 33.8688 4 1 0x100 0x0b 0 84 motorola section 5 instruction cache 5-1 section 5 instruction cache 5.1 instruction cache features 8kbyte direct-mapped cache single-cycle access on cache hits physically located on the coldfire ? core high-speed local bus nonblocking design to maximize performance 16 byte line-fill buffer configurable cache miss-fetch algorithm 5.2 instruction cache physical organization the instruction cache is a direct-mapped single-cycle memory, organized as 512 lines, each containing 16 bytes. the memory storage consists of a 512-entry tag array (containing addresses and a valid bit), and the data array containing 8kbytes of instruction data, organized as 2048 x 32 bits. the two memory arrays are accessed in parallel: bits [12:4] of the instruction fetch address provide the index into the tag array, and bits [12:2] addressing the data array. the tag array outputs the address mapped to the given cache location along with the valid bit for the line. this address field is compared to bits [31:12] of the instruction fetch address from the local bus to determine if a cache hit in the memory array has occurred. if the desired address is mapped into the cache memory, the output of the data array is driven onto the coldfire core's local data bus completing the access in a single cycle. the tag array maintains a single valid bit per line entry. accordingly, only entire 16 byte lines are loaded into the instruction cache. the instruction cache also contains a 16 byte fill buffer that provides temporary storage for the last line fetched in response to a cache miss. with each instruction fetch, the contents of the line fill buffer are examined. thus, each instruction fetch address examines both the tag memory array and the line fill buffer to see if the desired address is mapped into either hardware resource. a cache hit in either the memory array or the line-fill buffer is serviced in a single cycle. because the line fill buffer maintains valid bits on a longword basis, hits in the buffer can be serviced immediately without waiting for the entire line to be fetched. if the referenced address is not contained in the memory array or the line-fill buffer, the instruction cache initiates the required external fetch operation. in most situations, this is a 16-byte line-sized burst reference. the hardware implementation is a nonblocking design, meaning the coldfire core's local bus is released after the initial access of a miss. thus, the cache or the sram module can service subsequent requests while the remainder of the line is being fetched and loaded into the fill buffer. 5-2 mcf5249um motorola instruction cache operation figure 5-1 instruction cache block diagram 5.3 instruction cache operation the instruction cache is physically connected to the coldfire core local bus, allowing it to service all instruction fetches from the coldfire core and certain memory fetches initiated by the debug module. typically, the debug module?s memory references appear as supervisor data accesses but the unit can be programmed to generate user-mode accesses and/or instruction fetches. the instruction cache processes any instruction fetch access in the normal manner. 5.3.1 interaction with other modules because both the instruction cache and high-speed sram module are connected to the coldfire core local data bus, certain user-defined configurations can result in simultaneous instruction fetch processing. if the referenced address is mapped into the sram module, that module will service the request in a single cycle. in this case, data accessed from the instruction cache is simply discarded and no external memory references are generated. if the address is not mapped into the sram space, the instruction cache handles the request in the normal fashion. 31 12 4 3 0 1 2 31 4 = = 31 9 31 0 ?127 31 0 0 local address bus line buffer address external data[31:0] line buffer data storage mux data mux fill hit tag valid local data bus tag hit instruction cache operation motorola section 5 instruction cache 5-3 5.3.2 memory reference attributes for every memory reference the coldfire core or the debug module generates, a set of ?effective attributes? is determined based on the address and the access control registers (acr0, acr1). this set of attributes includes the cacheable/noncacheable definition, the precise/imprecise handling of operand write, and the write-protect capability. in particular, each address is compared to the values programmed in the access control registers (acr). if the address matches one of the acr values, the access attributes from that acr are applied to the reference. if the address does not match either acr, then the default value defined in the cache control register (cacr) is used. the specific algorithm is as follows: if (address = acr0_address including mask) effective attributes = acr0 attributes else if (address = acr1_address including mask) effective attributes = acr1 attributes else effective attributes = cacr default attributes 5.3.3 cache coherency and invalidation the instruction cache does not monitor coldfire core data references for accesses to cached instructions. therefore, software must maintain cache coherency by invalidating the appropriate cache entries after modifying code segments. the cache invalidation can be performed in two ways. the assertion of bit 24 in the cacr forces the entire instruction cache to be marked as invalid. the invalidation operation requires 512 cycles because the cache sequences through the entire tag array, clearing a single location each cycle. any subsequent instruction fetch accesses are postponed until the invalidation sequence is complete. the privileged cpushl instruction can invalidate a single cache line. when this instruction is executed, the cache entry defined by bits[12:4] of the source address register is invalidated, provided bit 28 of the cacr is cleared. these invalidation operations can be initiated from the coldfire core or the debug module. 5.3.4 reset a hardware reset clears the cacr disabling the instruction cache. the contents of the tag array are not affected by the reset. accordingly, the system startup code must explicitly perform a cache invalidation by setting cacr[24] before the cache can be enabled. 5.3.5 cache miss fetch algorithm/line fills as detailed in section 5.2 instruction cache physical organization , the instruction cache hardware includes a 16-byte line fill buffer for providing temporary storage for the last fetched instruction. with the cache enabled as defined by cacr[31], a cacheable instruction fetch that misses in both the tag memory and the line-fill buffer generates a external fetch. the size of the external fetch is determined by the value contained in the 2-bit clnf field of the cacr and the miss address. table 5-1 shows the relationship between the clnf bits, the miss address, and the size of the external fetch. depending on the runtime characteristics of the application and the memory response speed, overall performance may be increased by programming the clnf bits to values {00, 01}. 5-4 mcf5249um motorola instruction cache operation for all cases of a line-sized fetch, the critical longword defined by bits [3:2] of the miss address is accessed first followed by the remaining three longwords that are accessed by incrementing the longword address in a modulo-16 fashion is shown in the following example code: if miss address[3:2] = 00 fetch sequence = {$0, $4, $8, $c} if miss address[3:2] = 01 fetch sequence = {$4, $8, $c, $0} if miss address[3:2] = 10 fetch sequence = {$8, $c, $0, $4} if miss address[3:2] = 11 fetch sequence = {$c, $0, $4, $8} once an external fetch has been initiated and the data loaded into the line-fill buffer, the instruction cache maintains a special ?most-recently-used? indicator that tracks the contents of the fill buffer versus its corresponding cache location. at the time of the miss, the hardware indicator is set, marking the fill buffer as ?most recently used.? if a subsequent access occurs to the cache location defined by bits [8:4] of the fill buffer address, the data in the cache memory array is now most recently used, so the hardware indicator is cleared. in all cases, the indicator defines whether the contents of the line fill buffer or the memory data array are most recently used. at the time of the next cache miss, the contents of the line-fill buffer are written into the memory array if the entire line is present, and the fill buffer data is still most recently used compared to the memory array. the fill buffer can also be used as temporary storage for line-sized bursts of non-cacheable references under control of cacr[10]. with this bit set, a noncacheable instruction fetch is processed as defined by table 5-2 . for this condition, the fill buffer is loaded and subsequent references can hit in the buffer, but the data is never loaded into the memory array. the following table shows the relationship between cacr bits 31 and 10 and the type of instruction fetch. table 5-1 initial fetch offset vs. clnf bits clnf[1:0] longword address bits 00 01 10 11 00 line line line longword 01 line line longword longword 1x line line line line instruction cache programming model motorola section 5 instruction cache 5-5 5.4 instruction cache programming model three supervisor registers define the operation of the instruction cache and local bus controller: the cache control register (cacr) and two access control registers (acr0, acr1). 5.4.1 instruction cache registers memory map table 5-3 shows the memory map of the instruction cache and access control registers. the following list describes several key issues regarding the programming model table: the cache control register and access control registers can only be accessed in supervisor mode using the movec instruction with an rc value of $002, $004 and $005, respectively. addresses not assigned to the registers and undefined register bits are reserved for future expansion. write accesses to these reserved address spaces and reserved register bits have no effect; read accesses will return zeros. the reset value column indicates the initial value of the register at reset. certain registers may be uninitialized upon reset, i.e., they may contain random values after reset. the access column indicates if the corresponding register allows both read/write functionality (r/w), read-only functionality (r), or write-only functionality (w). if a read access to a write-only register is attempted, zeros will be returned. if a write access to a read-only register is attempted the access will be ignored and no write will occur. table 5-2 instruction cache operation as defined by cacr[31,10] cacr[31] cacr[10] type of instr. fetch description 0 0 n/a instruction cache is completely disabled; all fetches are word, longword in size. 0 1 n/a all fetches are word, longword in size 1 x cacheable fetch size is defined by table 4-1 and contents of the line-fill buffer can be written into the memory array 1 0 noncacheable all fetches are longword in size, and not loaded into the line-fill buffer 1 1 noncacheable fetch size is defined by table 4-1 and loaded into the line-fill buffer, but are never written into the memory array. 5-6 mcf5249um motorola instruction cache programming model 5.4.2 instruction cache register 5.4.2.1 cache control register the cacr controls the operation of the instruction cache. the cacr provides a set of default memory access attributes used when a reference address does not map into the spaces defined by the acrs. the cacr is a 32-bit write-only supervisor control register. it is accessed in the cpu address space using the movec instruction with an rc encoding of $002. the cacr can be read when in background debug mode (bdm). at system reset, the entire register is cleared. table 5-3 memory map of i-cache registers address name width description reset value access movec with $002 cacr 32 cache control register $0000 w movec with $004 acr0 32 access control register 0 $0000 w movec with $005 acr1 32 access control register 1 $0000 w table 5-4 cache control register (cacr) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field cenb cpdi cfrz reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r/w r/w r/w r/w bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field ceib dcm dbwe dwp clnf1 clnf2 reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r/w r/w r/w r/w r/w r/w r/w instruction cache programming model motorola section 5 instruction cache 5-7 table 5-5 cache control bit descriptions bit name description cenb the cache enable bit genera lly provides longword refe rences used for sequential fetches. if the processor branches to an odd word address, a word-sized fetch is generated. the memory array of the instruction cache is enabled only if cenb is asserted. 0 = cache disabled 1 = cache enabled cpdi when the disable cpushl invalidation instruction is executed, the cache entry defined by bits [8:4] of the address is invalidated if cpdi = 0. if cpdi = 1, no operation is performed. 0 = enable invalidation 1 = disable invalidation cfrz the cache freeze bit allows users to freeze the cont ents of the cache. when cfrz is asserted line fetches can be initiated and loaded into the line-fill buffer, but a valid cache entry can not be overwritten. if a given cache location is invalid, the contents of the line-fill bu ffer can be written into the memory array while cfrz is asserted. 0 = normal operation 1 = freeze valid cache lines cinv the cache invalidate bit forces the cache to invalidate each tag array entry. the invalidation process requires 32 machine cycles, with a single cache entry cleared per machine cycle. the state of this bit is always read as a zero. after a hardware reset, the cache must be invalidated before it is enabled. 0 = no operation 1 = invalidate all cache locations ceib the cache enable noncacheable instruction bursting bit enables the line-fill buffer to be loaded with burst transfers under control of clinf[1:0] for non-cacheabl e accesses. noncacheable accesses are never written into the memory array. 0 = disable burst fetches on noncacheable accesses 1 = enable burst fetches on noncacheable accesses dcm the default cache mode bit defines the default cac he mode: 0 is cacheable, 1 is noncacheable. for more information on the selection of the effective memory attributes, see . 0 = default cacheable 1 = default noncacheable dbwe the default buffered write enable bit defines the defaul t value for enabling buffered writes. if dbwe = 0, the termination of an operand write cycle on the processor?s local bus is delayed until the external bus cycle is completed. if dbwe = 1, the write cycle on the loca l bus is terminated immediately and the operation buffered in the bus controller. in this mode, operand write cy cles are effectively decoupled between the processor?s local bus and the external bus. generally, enabled buffered writes provide higher system performance but recovery from access errors can be more difficult. for the coldfire cpu, reporting ac cess errors on operand writes is always imprecise and enabling buffered writes simply fu rther decouples the write instruction from the signaling of the fault 0 = disable buffered writes 1 = enable buffered writes dwp default write protection 0 = read and write accesses permitted 1 = only read accesses permitted clnf[1:0] the cache line fill bits control the size of the memory request the cache issues to the bus controller for different initial line access offsets. the following table shows the fetch size. 5-8 mcf5249um motorola instruction cache programming model 5.4.2.2 access control registers the access control registers acr0 and acr1, provide a definition of memory reference attributes for two memory regions (one per acr). this set of effective attributes is defined for every memory reference using the acrs or the set of default attributes contained in the cacr. the acrs are examined for every memory reference that is not mapped to the sram module. the acrs are 32-bit write-only supervisor control registers. they are accessed in the cpu address space using the movec instruction with an rc encoding of $004 and $005. the acrs can be read when in background debug mode (bdm). at system reset, the registers are cleared. table 5-6 external fetch size based on miss address and clnf clnf[1:0] longword address bits 00 01 10 11 00 line line line longword 01 line line longword longword 10 line line line line 11 line line line line table 5-7 access control registers (acro, acr1) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field ba31 ba30 ba29 ba28 ba27 ba26 ba25 ba24 bam3 1 bam3 0 bam29 bam 28 bam2 7 bam2 6 bam2 5 bam2 4 reset 000 0 0000 0 0 0 0 0 0 0 0 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field en sm1 sm0 cm bwe wp reset 000 0 0000 0 0 0 0 0 0 0 0 r/w r/w r/w r/w r/w r/w r/w instruction cache programming model motorola section 5 instruction cache 5-9 table 5-8 access control bit descriptions bit name description ab[31:24] the address base [31:24] 8-bit field is compared to address bits [31:24] from the processor?s local bus under control of the acr address mask. if the address matches, the attributes for the memory reference are sourced from the given acr. am[31:24] the address mask [31:24] 8-bit field can mask any bit of the ab field comparison. if a bit in the am field is set, then the corresponding bit of the address field comparison is ignored. en the enable bit defines the acr enable. hardware reset clears this bit, disabling the acr. 0 = acr disabled 1 = acr enabled sm[1:0] the supervisor mode two-bit field allows the given acr to be applied to references based on operating privilege mode of the coldfire processor. the field uses the acr for user references only, supervisor references only, or all accesses. 00 = match if user mode 01 = match if supervisor mode 1x = match always - ignore user/supervisor mode cm the cache mode bit defines the cache mode: 0 is cacheable, 1 is noncacheable. 0 = caching enabled 1 = caching disabled bwe the buffered write enable bit defines the value for enabling buffered writes. if bwe = 0, the termination of an operand write cycle on the processor?s local bus is delayed until the external bus cycle is completed. if bwe = 1, the write cycle on the local bus is terminated immediately and the operation is then buffered in the bus controller. in this mode, operand write cycles are effectively decoupled between the processor?s local bus and the external bus. generally, the enabling of buffered writes provides higher system performance but recovery from access errors may be more difficult. for the coldfire cpu, the reporting of access errors on operand writes is always imprecise, and enabling buffered writes simply decouples the write instruction from the signaling of the fault even more. 0 = don?t buffer writes 1 = buffer writes wp the write protect bit defines the write-protection attribute. if the effective memory attributes for a given access select the wp bit, an access error terminates any attempted write with this bit set. 0 = read and write accesses permitted 1 = only read accesses permitted 5-10 mcf5249um motorola notes motorola section 6 static ram (sram) 6-1 section 6 static ram (sram) 6.1 sram features one 64 kbyte and one 32 kbyte srams single-cycle access physically located on processor's high-speed local bus memory location programmable on any 32 kbyte address byte, word, longword address capabilities 6.2 sram operation the sram module provides a general-purpose memory block that the coldfire processor can access in a single cycle. the location of the memory block can be specified to any modulo-16k address within the 4-gbyte address space. the memory is ideal for storing critical code or data structures or for use as the system stack. because the sram module is physically connected to the processor's high-speed local bus, it can service processor-initiated access or memory-referencing commands from the debug module. depending on configuration information, instruction fetches may be sent to both the cache and the sram block simultaneously. if the reference is mapped into the region defined by the sram, the sram provides the data back to the processor, and the cache data discarded. accesses from the sram module are not cached. the first sram, sram0 (32 kbytes) cannot be accessed by the on-chip dmas of the mcf5249. the second sram, sram1 (64 kbytes), can be accessed by the on-chip dmas. sram0 is made up of one memory array consisting of 2048 lines, each containing 16 bytes. however, sram1 is made up of two memory arrays each consisting of 2048 lines, with 16 bytes in each line. the sram1 array is split (upper 32k bank and lower 32k bank) to allow simultaneous access to both arrays by both the dma and the cpu. figure 1-1 in section 1.2 , the mcf5249 block diagram, shows this concept. 6.3 sram programming model the sram programming model includes a description of the sram base address register (rambar), sram initialization, and power management. 6.3.1 sram base address register the configuration information in the sram base address register (rambar[0:1]) controls the operation of the sram module. there are 2 rambar registers. one for sram0, the second for sram1. the rambar is the register that holds the base address of the sram. the movec instruction provides write-only access to this register. the rambar registers can be read or written from the debug module in a similar manner. all undefined bits in the register are reserved. these bits are ignored during writes to the rambar, and return zeroes when read from the debug module. the rambar valid bit is cleared by reset, disabling the sram module. all other bits are unaffected. 6-2 mcf5249um motorola sram programming model the rambar register contains several control fields. these fields are detailed in the following tables. table 6-1 sram base address register (rambar0) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field ba31 ba30 ba29 ba28 ba27 ba26 ba25 ba2 4ba23ba22ba21ba20ba19ba18ba17ba16 reset???????????????? r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w bits 1514131211109876543210 field ba15 ba14 wp c/i sc sd uc ud v reset??????????????? 0 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w cpu + $c04 table 6-2 sram1 base address register (rambar1) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field ba31 ba30 ba29 ba28 ba27 ba26 ba25 ba2 4ba23ba22ba21ba20ba19ba18ba17ba16 reset???????????????? r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w bits 1514131211109876543210 field ba15 ba14 pri1 pri2 spv wp c/i sc sd uc ud v reset??????????????? 0 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w cpu + $c05 sram programming model motorola section 6 static ram (sram) 6-3 table 6-3 cache control bit descriptions bit name description ba[31:14] the base address field defines the 0-modulo-16k base address of the sram module. the sram memory occupies a 16kbyte space defined by the contents of the base address field. by programming this field, the sram may be located on any 16kbyte boundary within the processor?s four gigabyte address space. pri1, pri2 the pri1 priority bit (only sram1) determines if dma or cpu has priority in upper 32k bank of memory. pri2 determines if dma or cpu has priority in lower 32k bank of memory. if bit is set, dma has priority. if bit is reset, cpu has priority. priority is determined by the following table: spv allow dma access (only sram1) 0 = dma access to memory is disabled. 1 = dma access to memory is enabled. wp the write protect field allows only read accesses to the sram. when this bit is set, any attempted write access will generate an access error exception to the coldfire processor core. 0 = allows read and write accesses to the sram module 1 = allows only read accesses to the sram module c/i, sc, sd, uc, ud address space masks (asn) these five bit fields allow certain types of accesses to be ?masked,? or inhibited from accessing the sram module. the address space mask bits are: c/i = cpu space/interrupt acknowledge cycle mask sc = supervisor code address space mask sd = supervisor data address space mask uc = user code address space mask ud = user data address space mask for each address space bit: 0 = an access to the sram module can occur for this address space 1 = disable this address space from the sram module. if a reference using this address space is made, it is inhibited from accessing the sram module, and is processed like any other non-sram reference. these bits are useful for power management as detailed in section 6.3.4. v the valid bit (v-bit) is specified by rambar[0:1]. a hardware reset clears this bit. when set, this bit enables the sram module; otherwise, the module is disabled. 0 = contents of rambar are not valid 1 = contents of rambar are valid pri[1:2] upper bank priority lower bank priority 2?b00 cpu accesses cpu accesses 2?b01 cpu accesses dma accesses 2?b10 dma accesses cpu accesses 2?b11 dma accesses dma accesses 6-4 mcf5249um motorola sram programming model 6.3.2 sram initialization after a hardware reset, the contents of the sram module are undefined. the valid bit of the rambar is cleared, disabling the module. if the sram requires initialization with instructions or data, the following steps should be performed: 1. load the rambar mapping the sram module to the desired location within the address space. 2. read the source data and write it to the sram. there are various instructions to support this function, including memory-to-memory move instructions, or the movem opcode. the movem instruction is optimized to generate line-sized burst fetches on 0-modulo-16 addresses, so this opcode generally provides maximum performance. 3. after the data has been loaded into the sram, it may be appropriate to load a revised value into the rambar with a new set of attributes. these attributes consist of the write-protect and address space mask fields. the coldfire processor or an external emulator using the debug module can perform these initialization functions. 6.3.3 sram initialization code the following code segment describes how to initialize the sram. the code sets the base address of the sram at $20000000 and then initializes the ram to zeros. rambase equ $20000000 set this variable to $20000000 ramvalid equ $00000000 move.l #rambase+ramvalid,d0;load rambase + valid bit into d0. movec.l d0, rambar;load rambar and enable sram the following loop initializes the entire sram to zero lea.l rambase,a0;load pointer to sram move.l #1024,d0;load loop counter into d0 sram_init_loop: clr.l (a0)+) clear 4 bytes of sram subq.l #1,d0;decrement loop counter bne.b sram_init_loop;if done, then exit; else continue looping 6.3.4 power management as noted previously, depending on the configuration defined by the rambar, instruction fetch and operand read accesses may be sent to the sram and unified cache simultaneously. if the access is mapped to the sram module, it sources the read data, and the unified cache access is discarded. if the sram is used only for data operands, asserting the asn bits associated with instruction fetches can decrease power dissipation. additionally, if the sram contains only instructions, masking operand accesses can reduce power dissipation. the following table shows some examples of typical rambar settings . table 6-4 typical rambar setting examples data contained in sram rambar[7:0] code only $2b data only $35 both code and data $21 motorola section 7 synchronous dram controller module 7-1 section 7 synchronous dram controller module 7.1 dram features the key features of the dram controller include the following: support for two independent blocks of dram interface to standard synchronous dynamic random access memory (sdram) components programmable sdras , sdcas , and refresh timing support for page mode support for 16- wide dram blocks 7.1.1 definitions the following terminology is used in this section: sdram block?any group of dram memories selected by one of the mcf5249 sdram_cs1 , sdram_cs2 signals. thus, the mcf5249 can support two independent memory blocks. the base address of each block is programmed in the dram address and control registers (dacr0 and dacr1). sdram?rams that operate like asynchronous drams but with a synchronous clock, a pipelined, multiple-bank architecture, and faster speed. sdram bank?an internal partition in an sdram device. for example, a 64-mbit sdram component might be configured as four 512k x 32 banks. banks are selected through the sdram component?s bank select lines. note: the sdram_cs2 signal is only used in the 160 mapbga package. 7.1.2 block diagram and major components the basic components of the dram controller are shown in figure 7-1 . 7-2 mcf5249um motorola dram controller operation figure 7-1 synchronous dram controller block diagram the dram controller?s major components, shown in figure 7-1 , are described as follows: dram address and control registers (dacr0 and dacr1)?the dram controller consists of two configuration register units, one for each supported memory block. dacr0 is accessed at mbar + 0x0108; dacr1 is accessed at 0x0110. the register information is passed on to the hit logic. control logic and state machine?generates all dram signals, taking bus cycle characteristic data from the block logic, along with hit information to generate dram accesses. handles refresh requests from the refresh counter. ? dram control register (dcr)?contains data to control refresh operation of the dram controller. both memory blocks are refreshed concurrently as controlled by dcr[rc]. ? refresh counter?determines when refresh should occur, determined by the value of dcr[rc]. it generates a refresh request to the control block. hit logic?compares address and attribute signals of a current dram bus cycle to both dacrs to determine if a dram block is being accessed. hits are passed to the control logic along with characteristics of the bus cycle to be generated. page hit logic?determines if the next dram access is in the same dram page as the previous one. this information is passed on to the control logic. address multiplexing?multiplexes addresses to allow column and row addresses to share pins. this allows glueless interface to drams. 7.2 dram controller operation 7.2.1 dram controller registers the dram controller registers memory map is shown in table 7-1 memory block 0 hit logic dram address/control register 0 (dacr0) a25, a[23:1] internal address control logic and dram controller module refresh counter state machine multiplexing page hit logic dram control register (dcr) bus memory block 1 hit logic dram address/control register 1 (dacr1) a[31:0] sdram_cs1 sdram_cs2 sdras sdcas sdwe sdudqm sdldqm bclke synchronous operation motorola section 7 synchronous dram controller module 7-3 . 7.3 synchronous operation by running synchronously with the system clock, sdram can (after an initial latency period) be accessed on every clock; 5-1-1-1 is a typical mcf5249 burst rate to sdram. note: because the mcf5249 cannot have more than one page open at a time, it does not support interleaving. table 7-2 lists common sdram commands. commands are issued to memory using specific encoding on address and control pins. soon after system reset, a command must be sent to the sdram mode register to configure sdram operating parameters. table 7-1 dram controller registers mbar offset [31:24] [23:16] [15:8] [7:0] 0x100 dram control register (dcr) [ 7.2.1 on page 7-2] reserved 0x104 reserved 0x108 dram address and control register 0 (dacr0) [see section 7.3.2.2 on page 7-7 .] 0x10c dram mask register block 0 (dmr0) [see section 7.3.2.3 on page 7-9 .] 0x110 dram address and control register 1 (dacr1) [see section 7.3.2.2 on page 7-7 .] 0x114 dram mask register block 1 (dmr1) [see section 7.3.2.3 on page 7-9 .] table 7-2 sdram commands command definition actv activate. executed before read or write executes; sdram registers and decodes row address. mrs mode register set. nop no-op. does not affect sdram state machine; dram controller control signals negated; sdram_cs asserted. pall precharge all. precharges all internal banks of an sdram component; executed before new page is opened. read read access. sdram registers column address and decodes that a read access is occurring. ref refresh. refreshes internal bank rows of an sdram component. self self refresh. refreshes internal bank rows of an sdram component when it is in low-power mode. selfx exit self refresh. this command is sent to the dram controller when dcr[is] is cleared. write write access. sdram registers column address and decodes that a write access is occurring. 7-4 mcf5249um motorola synchronous operation note: after synchronous operation is selected by setting dcr[so], dram controller registers reflect the synchronous operation. 7.3.1 dram controller sign als in synchronous mode table 7-3 shows the behavior of dram signals in synchronous mode. note: the sdram_cs2 is only used in the 160 mapbga package. table 7-3 synchronous dram signal connections signal description sdras synchronous row address strobe. indicates a valid sdram row address is present and can be latched by the sdram. sdras should be connected to the corresponding sdram sras . sdcas synchronous column address strobe. indicates a valid column address is present and can be latched by the sdram. sdcas should be connected to the corresponding signal labeled scas on the sdram. sdwe dram read/write. asserted for write operations and negated for read operations. sdram_cs1 sdram_cs2 select each memory block of sdrams connected to the mcf5249. one signal selects one sdram block and connects to the corresponding cs signals. bclke synchronous dram clock enable. connected directly to the cke (clock enable) signal of sdrams. enables and disables the clock internal to sdram. when bclke is low, memory can enter a power-down mode where operations are suspended or they can enter self-refresh mode. bclke functionality is controlled by dcr[coc]. for designs using external multiplexing, setting coc allows bclke to provide command-bit functionality. udqm ldqm column address strobe. for synchronous operation, udqm, ldqm function as byte enables to the sdrams. they connect to the dqm signals (or mask qualifiers) of the sdrams. bclk bus clock output. connects to the clk input of sdrams. synchronous operation motorola section 7 synchronous dram controller module 7-5 figure 7-2 shows a typical signal configuration for synchronous mode. figure 7-2 mcf5249 sdram interface 7.3.2 synchronous register set the memory map is shown in table 7-1 . bit descriptions are shown in the following sections. 7.3.2.1 dram control register (dcr) (synchronous mode) the dram control register (dcr), figure 7-3 , controls refresh logic. table 7-4 describes dcr fields. 1514131211109876543210 field so ? nam coc is rtim rc reset 0 uninitialized r/w r/w addr mbar + 0x100 figure 7-3 dram control register (dcr) (synchronous mode) bclk a[31:0] dqm sdwe sdcas sdras bclke cke cas ras dqm we address data clk mcf5249 d[31:0] sdram cs sdram_cs1 7-6 mcf5249um motorola synchronous operation table 7-4 dcr field descriptions (synchronous mode) bits name description 15 so synchronous operation. selects synchronous or asynchronous mode. when in synchronous mode, the dram controller can be switched to adram mode only by resetting the mcf5249. 0 asynchronous drams. default at reset. do not use. 1 synchronous drams note: bit setting so=0 is a legacy mode. do not use. first action must always be to set this bit one. 14 ? reserved, should be cleared. 13 nam no address multiplexing. some implementations require external multiplexing. for example, when linear addressing is required, the dram should not multiplex addresses on dram accesses. 0 the dram controller multiplexes the external address bus to provide column addresses. 1 the dram controller does not multiplex the external address bus to provide column addresses. 12 coc command on sdram clock enable (scke). implementations that use external multiplexing (nam = 1) must support command information to be multiplexed onto the sdram address bus. 0 scke functions as a clock enable; self-refresh is initiated by the dram controller through dcr[is]. 1 scke drives command information. because scke is not a clock enable, self-refresh cannot be used (setting dcr[is]). thus, external logic must be used if this functionality is desired. external multiplexing is also responsible for putting the command information on the proper address bit. 11 is initiate self-refresh command. 0 take no action or issue a selfx command to exit self refresh. 1 if dcr[coc] = 0, the dram controller sends a self command to both sdram blocks to put them in low-power, self-refresh state where they remain until is is cleared, at which point the controller sends a selfx command for the sdrams to exit self-refresh. the refresh counter is suspended while the sdrams are in self-refresh; the sdram controls the refresh period. 10?9 rtim refresh timing. determines the timing operation of auto-refresh in the dram controller. specifically, it determines the number of clocks inserted between a ref command and the next possible actv command. this same timing is used for both memory blocks controlled by the dram controller. this corresponds to t rc in the sdram specifications. 00 3 clocks 01 6 clocks 1x 9 clocks 8?0 rc refresh count. controls refresh frequency. the number of bus clocks between refresh cycles is (rc + 1) * 16. refresh can range from 16?8192 bus clocks to accommodate both standard and low-power drams with bus clock operation from less than 2 mhz to greater than 50 mhz. the following example calculates rc for an auto-refresh period for 4096 rows to receive 64 ms of refresh every 15.625 s for each row (625 bus clocks at 40 mhz). # of bus clocks = 625 = (rc field + 1) * 16 rc = (625 bus clocks/16) -1 = 38.06, which rounds to 38; therefore, rc = 0x26. synchronous operation motorola section 7 synchronous dram controller module 7-7 7.3.2.2 dram address and cont rol (dacr0/dacr1) (synchronous mode) the dram address and control registers (dacr0 and dacr1), shown in figure 7-4 , contain the base address compare value and the control bits for both memory blocks 0 and 1 of the dram controller. address and timing are also controlled by bits in dacr n . table 7-5 describes dacr n fields. 31 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field ba ? re ? cas l ?cbm?imr s ps ip pm ? reset uninitialized 0 uninitialized 0 uninitialized r/w r/w addr mbar+0x108 (dacr0); 0x110 (dacr1) figure 7-4 dacr0 and dacr1 (synchronous mode) table 7-5 dacr0/dacr1 field descriptions (synchronous mode) bit name description 31?18 ba base address register. with dcmr[bam], determines the address range in which the associated dram block is located. each ba bit is compared with the corresponding address of the current bus cycle. if all unmasked bits match, the address hits in the associated dram block. 17?16 ? reserved, should be cleared. 15 re refresh enable. determines when the dram controller generates a refresh cycle to the dram block. 0 do not refresh associated dram block 1 refresh associated dram block 14 ? reserved, should be cleared. 13?12 casl cas latency. affects the following sdram timing specifications. timing nomenclature varies with manufacturers. refer to the sdram specification for the appropriate timing nomenclature: parameter number of bus clocks casl= 00 casl = 01 casl= 10 casl= 11 t rcd ?sras assertion to scas assertion 2 3 3 t casl ?scas assertion to data out 1 2 2 t ras ? actv command to precharge command 4 6 6 t rp ?precharge command to actv command 2 3 3 t rwl , t rdl ?last data input to precharge command 1 1 1 t ep ?last data out to precharge command) 1 1 1 11 ? reserved, should be cleared. 7-8 mcf5249um motorola synchronous operation 10?8 cbm command and bank mux [2:0]. because different sdram configurations cause the command and bank select lines to correspond to different addresses, these resources are programmable. cbm determines the addresses onto which these functions are multiplexed. cbmcommand bitbank select bits 000 17 18 and up 001 18 19 and up 010 19 20 and up 011 20 21 and up 100 21 22 and up 101 22 23 and up 110 23 24 and up 111 24 25 and up this encoding and the address multiplexing scheme handle common sdram organizations. bank select bits include a base bit and all address bits above for sdrams with multiple bank select bits. 7 ? reserved, should be cleared. 6 imrs initiate mode register set ( mrs ) command. setting imrs generates a mrs command to the associated sdrams. in initialization, imrs should be set only after all dram controller registers are initialized and pall and refresh commands have been issued. after imrs is set, the next access to an sdram block programs the sdram?s mode register. thus, the address of the access should be programmed to place the correct mode information on the sdram address pins. because the sdram does not register this information, it doesn?t matter if the imrs access is a read or a write or what, if any, data is put onto the data bus. the dram controller clears imrs after the mrs command finishes. 0 take no action 1 initiate mrs command 5?4 ps port size. indicates the port size of the associated block of sdram, which allows for dynamic sizing of associated sdram accesses. 1x 16-bit port 0x do not use. 3 ip initiate precharge all ( pall ) command. the dram controller clears ip after the pall command is finished. accesses using ip should be no wider than the port size programmed in ps. 0 take no action. 1a pall command is sent to the associated sdram block. during initialization, this command is executed after all dram controller registers are programmed. after ip is set, the next write to an appropriate sdram address generates the pall command to the sdram block. 2 pm page mode. indicates how the associated sdram block supports page-mode operation. 0 page mode on bursts only. the dram controller dynamically bursts the transfer if it falls within a single page and the transfer size exceeds the port size of the sdram block. after the burst, the page closes and a precharge is issued. 1 continuous page mode. the page stays open and only sdcas needs to be asserted for sequential sdram accesses that hit in the same page, regardless of whether the access is a burst. 1?0 ? reserved, should be cleared. table 7-5 dacr0/dacr1 field descriptions (synchronous mode) (continued) bit name description synchronous operation motorola section 7 synchronous dram controller module 7-9 7.3.2.3 dram controller mask registers (dmr0/dmr1) the dmr n , figure 7-5 , includes mask bits for the base address and for address attributes. table 7-6 describes dmr n fields. 31 1817 9876543210 field bam ? w p ? c/i am sc sd uc ud v reset uninitialized 0 r/w r/w addr mbar + 0x10c (dmr0), 0x114 (dmr1) figure 7-5 dram controller mask registers (dmr0 and dmr1) table 7-6 dmr0/dmr1 field descriptions bits name description 31?18 bam base address mask. masks the associated dacr n [ba]. lets the dram controller connect to various dram sizes. mask bits need not be contiguous (see section 7.4, ?sdram example .?) 0 the associated address bit is used in decoding the dram hit to a memory block. 1 the associated address bit is not used in the dram hit decode. 17?9 ? reserved, should be cleared. 8 wp write protect. determines whether the associated block of dram is write protected. 0 allow write accesses 1 ignore write accesses. the dram controller ignores write accesses to the memory block and an address exception occurs. write accesses to a write-protected dram region are compared in the chip select module for a hit. if no hit occurs, an external bus cycle is generated. if this external bus cycle is not acknowledged, an access exception occurs. 7 ? reserved, should be cleared. 6?1 am x address modifier masks. determine which accesses can occur in a given dram block. 0 allow access type to hit in dram 1 do not allow access type to hit in dram bit associated access type access definition c/i cpu space/interrupt acknowledge movec instruction or interrupt acknowledge cycle am alternate master external or dma master sc supervisor code any supervisor-only instruction access sd supervisor data any data fetched during the instruction access uc user code any user instruction ud user data any user data 0 v valid. cleared at reset to ensure that the dram block is not erroneously decoded. 0 do not decode dram accesses. 1 registers controlling the dram block are initialized; dram accesses can be decoded. 7-10 mcf5249um motorola synchronous operation 7.3.3 general synchronous operation guidelines to reduce system logic and to support a variety of sdram sizes, the dram controller provides sdram control signals as well as a multiplexed row address and column address to the sdram. when sdram blocks are accessed, the dram controller can operate in either burst or continuous page mode. the following sections describe the dram controller interface to sdram, the supported bus transfers, and initialization. 7.3.3.1 address multiplexing table 7-7 shows the generic address multiplexing scheme for sdram configurations. all possible address connection configurations can be derived from this table. the following tables provide a more comprehensive, step-by-step way to determine the correct address line connections for interfacing the mcf5249 to sdram. to use the tables, find the one that corresponds to the number of column address lines on the sdram and to the port size as seen by the mcf5249, which is not necessarily the sdram port size. for example, if two 1m x 16-bit sdrams together form a 1m x 32-bit memory, the port size is 32 bits. most sdrams likely have fewer address lines than are shown in the tables, so follow only the connections shown until all sdram address lines are connected. table 7-7 sdram interface (8-bit port,10-column address lines) mcf5249 pins a17 a16 a15 a14 a13 a12 a11 a10 a9 a19 a20 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 row 1716151413121110 9 19 20 21 22 23 24 25 26 27 28 29 30 31 column 012345678 18 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 a20 a21 table 7-8 sdram interface (16-bit port,11-column address lines) mcf5249 pins a17 a16 a15 a14 a13 a12 a11 a10 a9 a19 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 row 17 16 15 14 13 12 11 10 9 19 21 22 23 24 25 26 27 28 29 30 31 column 0123456781820 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 a20 table 7-9 sdram interface (16-bit port,12-column address lines) mcf5249 pins a17 a16 a15 a14 a13 a12 a11 a10 a9 a19 a21 a23 a24 a25 a26 a27 a28 a29 a30 a31 row 17161514131211 1091921232425262728293031 column 0123456 78182022 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 synchronous operation motorola section 7 synchronous dram controller module 7-11 table 7-10 sdram interface (16-bit port, 8-column address lines) mcf5249 pins a16 a15 a14 a13 a12 a11 a10 a9 a17 a18 a19 a20 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 row 16151413121110 9 171819202122232425262728293031 column 12345678 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a 13 a14 a15 a16 a17 a18 a19 a20 a21 a22 table 7-11 sdram interface (16-bit port, 9-column address lines) mcf5249 pins a16 a15 a14 a13 a12 a11 a10 a9 a18 a19 a20 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 row 16151413121110 9 1819202122232425262728293031 column 1234567817 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 a20 a21 table 7-12 sdram interface (16-bit port, 10-column address lines) pins a16 a15 a14 a13 a12 a11 a10 a9 a18 a20 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 row 16 15 14 13 12 11 10 9 18 20 21 22 23 24 25 26 27 28 29 30 31 column123456781719 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 a20 table 7-13 sdram interface (16-bit port, 11-column address lines) pins a16 a15 a14 a13 a12 a11 a10 a9 a18 a20 a22 a24 a25 a26 a27 a28 a29 a30 a31 a16 row 16 15 14 13 12 11 10 9 18 20 22 23 24 25 26 27 28 29 30 31 column 1 2345 6 78171921 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 table 7-14 sdram interface (16-bit port, 12-column address lines) mcf5249 pins a16 a15 a14 a13 a12 a11 a10 a9 a18 a20 a22 a24 a25 a26 a27 a28 a29 a30 a31 row 16151413121110 9 1820222425262728293031 column 1234567817192123 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 table 7-15 sdram interface (16-bit port, 13-column-address lines) mcf5249 pins a16 a15 a14 a13 a12 a11 a10 a9 a18 a20 a22 a24 a26 a27 a28 a29 a30 a31 row 16151413121110 9 18202224262728293031 column 1 2 3 4 5 6 7 8 1719212325 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 7-12 mcf5249um motorola synchronous operation 7.3.3.2 interfacing example the tables in the previous section can be used to configure the interface in the following example. to interface one 1m x 16-bit x 4 bank sdram component (8 columns) to the mcf5249, the connections would be as shown in table 7-19 . 7.3.3.3 burst page mode sdram can efficiently provide data when an sdram page is opened. as soon as sdcas is issued, the sdram accepts a new address and asserts sdcas every clock for as long as accesses are in that page. in burst page mode, there are multiple read or write operations for every actv command in the sdram if the requested transfer size exceeds the port size of the associated sdram. the primary cycle of the transfer generates the actv and read or write commands; secondary cycles generate only read or write commands. as soon as the transfer completes, the pall command is generated to prepare for the next access. note: in synchronous operation, burst mode and address incrementing during burst cycles are controlled by the mcf5249 dram controller. thus, instead of the sdram enabling its internal burst incrementing capability, the mcf5249 controls this function. this means that the burst function that is enabled in the mode register of sdrams must be disabled when interfacing to the mcf5249. table 7-16 sdram interface (16-bit port, 9-column address lines) pins a15 a14 a13 a12 a11 a10 a9 a17 a19 a20 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 row 15 14 13 12 11 10 9 17 19 20 21 22 23 24 25 26 27 28 29 30 31 column 23456781618 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 a20 table 7-17 sdram interface (16-bit port, 10-column address lines) mcf5249 pins a15 a14 a13 a12 a11 a10 a9 a17 a19 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 row 15 14 13 12 11 10 9 17 19 21 22 23 24 25 26 27 28 29 30 31 column 2345678161820 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 table 7-18 sdram interface (16-bit port, 11-column address lines) mcf5249 pins a15 a14 a13 a12 a11 a10 a9 a17 a19 a21 a23 a24 a25 a26 a27 a28 a29 a30 a31 row 151413121110 9 171921232425262728293031 column 234567816182022 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 table 7-19 sdram hardware connections sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 = cmd a11 ba0 ba1 mcf5249 pins a16 a15 a14 a13 a12 a11 a10 a9 a17 a18 a19 a20 a21 a22 synchronous operation motorola section 7 synchronous dram controller module 7-13 figure 7-6 shows a burst read operation. in this example, dacr[casl] = 01, for an sras -to-scas delay (t rcd ) of 1bclko cycles. because t rcd is one more than the read cas latency (scas assertion to data out), this value is 2 bclko cycles. notice that nop s are executed until the last data is read. a pall command is executed one cycle after the last data transfer. figure 7-6 burst read sdram access figure 7-7 shows the burst write operation. in this example, dacr[casl] = 01, which creates an sras -to-scas delay (t rcd ) of 2 bclko cycles. note: data is available upon scas assertion and a burst write cycle completes two cycles sooner than a burst read cycle with the same t rcd. the next bus cycle is initiated sooner, but cannot begin an sdram cycle until the precharge-to- actv delay completes. a[31:0] sdras sdcas sdwe d[31:0] t casl = 1 actv read nop nop sdram_cs0 udqm nop pall row column column column column trcd = 2 t ep bclk ldqm 7-14 mcf5249um motorola synchronous operation figure 7-7 burst write sdram access accesses in synchronous burst page mode always cause the following sequence: 1. actv command 2. nop commands to assure sras -to-scas delay (if cas latency is 1, there are no nop commands). 3. required number of read or write commands to service the transfer size with the given port size. 4. some transfers need more nop commands to assure the actv -to-precharge delay. 5. pall command 6. required number of idle clocks inserted to assure precharge-to- actv delay. 7.3.3.4 continuous page mode continuous page mode is identical to burst page mode, except that it allows the processor core to handle successive bus cycles that hit the same page without having to close the page. when the current bus cycle finishes, the mcf5249 core internal pipelined bus can predict whether the upcoming cycle will hit in the same page. if the next bus cycle is not pending or misses in the page, the pall command is generated to the sdram. if the next bus cycle is pending and hits in the page, the page is left open, and the next sdram access begins with a read or write command. because of the nature of the internal cpu pipeline this condition does not occur often; however, the use of continuous page mode is recommended because it can provide a slight performance increase. figure 7-8 shows two read accesses in continuous page mode. a[31:0] sdras sdcas sdwe d[31:0] actv write pall nop sdram_cs0 xdqm t casl = 2 row column column column column t rp t rwl bclk nop synchronous operation motorola section 7 synchronous dram controller module 7-15 note: there is no precharge between the two accesses. also, the second cycle begins with a read operation with no actv command. figure 7-8 synchronous, continuous page-mode access?consecutive reads figure 7-9 shows a write followed by a read in continuous page mode. because the bus cycle is terminated with a write command, the second cycle begins sooner after the write than after the read. a read requires data to be returned before the bus cycle can terminate. note: in continuous page mode, secondary accesses output the column address only. a[31:0] sdras sdcas sdwe d[31:0] actv nop read nop sdram_cs0 xdqm read nop nop pall tcasl = 1 trcd = 2 tcasl = 1 tep row column column bclk 7-16 mcf5249um motorola synchronous operation figure 7-9 synchronous, continuous page-mode access?read after write 7.3.3.5 auto-refresh operation the dram controller is equipped with a refresh counter and control. this logic is responsible for providing timing and control to refresh the sdram. once the refresh counter is set, and refresh is enabled, the counter counts to zero. at this time, an internal refresh request flag is set and the counter begins counting down again. the dram controller completes any active burst operation and then performs a pall operation. the dram controller then initiates a refresh cycle and clears the refresh request flag. this refresh cycle includes a delay from any precharge to the auto-refresh command, the auto-refresh command, and then a delay until any actv command is allowed. any sdram access initiated during the auto-refresh cycle is delayed until the cycle is completed. figure 7-10 shows the auto-refresh timing. in this case, there is an sdram access when the refresh request becomes active. the request is delayed by the precharge to actv delay programmed into the active sdram bank by the cas bits. the ref command is then generated and the delay required by dcr[rtim] is inserted before the next actv command is generated. in this example, the next bus cycle is initiated, but does not generate an sdram access until t rc is finished. because both chip selects are active during the ref command, it is passed to both blocks of external sdram. a[31:0] sdras sdcas sdwe d[ 31:0] actv nop read nop sdram_cs0 ] xdqm write nop nop nop pall row column column t casl = 2 t rcd = 3 t ep bclk synchronous operation motorola section 7 synchronous dram controller module 7-17 figure 7-10 auto-refresh operation 7.3.3.6 self-refresh operation self-refresh is a method of allowing the sdram to enter into a low-power state, while at the same time to perform an internal refresh operation and to maintain the integrity of the data stored in the sdram. the dram controller supports self-refresh with dcr[is]. when is is set, the self command is sent to the sdram. when is is cleared, the selfx command is sent to the dram controller. figure 7-11 shows the self-refresh operation. figure 7-11 self-refresh operation a[31:0] sdras sdcas sdwe pall nop nop sdram_cs ref actv t rcd = 2 t rc = 6 bclko sdras sdcas sdwe pall nop nop sdram_cs0 self first bclke possible actv selfx self- refresh active t rcd = 2 t rc = 6 bclk (dcr[coc] = 0) 7-18 mcf5249um motorola synchronous operation 7.3.4 initialization sequence synchronous drams have a prescribed initialization sequence. the dram controller supports this sequence with the following procedure: 1. sdram control signals are reset to idle state. wait the prescribed period after reset before any action is taken on the sdrams. this is normally around 100 s. 2. initialize the dcr, dacr, and dmr in their operational configuration. do not yet enable pall or ref commands. 3. issue a pall command to the sdrams by setting dcr[ip] and accessing a sdram location. wait the time (determined by t rp ) before any other execution. 4. enable refresh (set dacr[re]) and wait for at least 8 refreshes to occur. 5. before issuing the mrs command, determine if the dmr mask bits need to be modified to allow the mrs to execute properly 6. issue the mrs command by setting dacr[imrs] and accessing a location in the sdram. note: mode register settings are driven on the sdram address bus, so care must be taken to change dmr[bam] if the mode register configuration does not fall in the address range determined by the address mask bits. after the mode register is set, dmr mask bits can be restored to their desired configuration. 7.3.4.1 mode register settings it is possible to configure the operation of sdrams, namely their burst operation and cas latency, through the sdram component?s mode register. cas latency is a function of the speed of the sdram and the bus clock of the dram controller. the dram controller operates at a cas latency of 1 or 2. although the mcf5249 dram controller supports bursting operations, it does not use the bursting features of the sdrams. because the mcf5249 can burst operand sizes of 1, 2, 4, or 16 bytes long, the concept of a fixed burst length in the sdrams mode register becomes problematic. therefore, the mcf5249 dram controller generates the burst cycles rather than the sdram device. because the mcf5249 generates a new address and a read or write command for each transfer within the burst, the sdram mode register should be set either to a burst length of one or to not burst. this allows bursting to be controlled by the mcf5249 instead. the sdram mode register is written by setting the associated block?s dacr[imrs]. first, the base address and mask registers must be set to the appropriate configuration to allow the mode register to be set. note: improperly set dmr mask bits may prevent access to the mode register address. thus, the user should determine the mapping of the mode register address to the mcf5249 address bits to find out if an access is blocked. if the dmr setting prohibits mode register access, the dmr should be reconfigured to enable the access and then set to its necessary configuration after the mrs command executes. the associated cbm bits should also be initialized. after dacr[imrs] is set, the next access to the sdram address space generates the mrs command to that sdram. the address of the access should be selected to place the correct mode information on the sdram address pins. the address is not multiplexed for the mrs command. the mrs access can be a read or write. the important thing is that the address output of that access needs the correct mode programming information on the correct address bits. figure 7-12 shows the mrs command, which occurs in the first clock of the bus cycle. sdram example motorola section 7 synchronous dram controller module 7-19 figure 7-12 mode register set ( mrs ) command 7.4 sdram example this example interfaces a samsung k4s641633 1m x 16-bit x 4 bank sdram component to a mcf5249 operating at 40 mhz (20 mhz bus). table 7-20 lists design specifications for this example. 7.4.1 sdram interface configuration to interface this component to the mcf5249 dram controller, use the connection table that corresponds to a 16-bit port size with 8 columns ( figure 7-14 ). two pins select one of four banks when the part is functional. table 7-21 shows the proper hardware hook-up. table 7-20 sdram example specifications parameter specification 12 rows, 8 columns two bank-select lines to access four internal banks actv -to-read/write delay (t rcd ) 20 ns (min.) period between auto refresh and actv command (t rc ) 70 ns actv command to precharge command (t ras ) 48 ns (min.) precharge command to actv command (t rp ) 20 ns (min.) last data input to pall command (t rwl ) 1 bus clock (25 ns) auto refresh period for 4096 rows (t ref )64 ms a[31:0] sdras , sdcas sdwe d[ 31:0] mrs sdram_cs1 bclk 7-20 mcf5249um motorola sdram example 7.4.2 dcr initialization at power-up, the dcr has the following configuration if synchronous operation and sdram address multiplexing is desired. this configuration results in a value of 0x8012 for dcr, as shown in table 7-22 . 7.4.3 dacr initialization as shown in figure 7-14 , in this example the sdram is programmed to access only the second 512-kbyte block of each 1-mbyte partition in the sdram (each 16 mbytes). the starting address of the sdram is 0xff80_0000. continuous page mode feature is used. table 7-21 sdram hardware connections mcf5249 pins a16 a15 a14 a13 a12 a11 a10 a9 a17 a18 a19 a20 a21 a22 sdram pins a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 = cmd a11 ba0 ba1 15 14 13 12 11 10 9 8 0 field so res na m co c is rtim rc setting 1x00000000010010 (hex) 80 1 2 figure 7-13 initialization values for dcr table 7-22 dcr initialization values bits name setting description 15 so 1 indicating synchronous operation 14 ? x don?t care (reserved) 13 nam 0 indicating sdram controller multiplexes address lines internally 12 coc 0 scke is used as clock enable instead of command bit because user is not multiplexing address lines externally and requires external command feed. 11 is 0 at power-up, allowing power self-refresh state is not appropriate because registers are being set up. 10?9 rtim 00 because t rc value is 70 ns, indicating a 3-clock refresh-to- actv timing. 8?0 rc 0x12 specification indicates auto-refresh period for 4096 rows to be 64 ms or refresh every 15.625 s for each row, or 312 bus clocks at 20mhz. because dcr[rc] is incremented by 1 and multiplied by 16, rc = (312 bus clocks/16) -1 = 18.56 = 0x12 sdram example motorola section 7 synchronous dram controller module 7-21 figure 7-14 sdram configuration the dacrs should be programmed as shown in figure 7-15 . this configuration results in a value of dacr0 = 0xff88_1224, as described in table 7-23 . dacr1 initialization is not needed because there is only one block. subsequently, dacr1[re,imrs,ip] should be cleared; everything else is a don?t care. 31 18 17 16 field ba ? setting 1111_1111_1000_10 xx (hex) 15 15 8 8 15 14 13 12 11 10 8 7 6 5 4 3 2 1 0 field re ? casl ? cbm ? imrs ps ip pm ? setting 0 x 01 x 010 x 0 10 0 1 xx (hex) 1 2 2 4 figure 7-15 dacr register configuration table 7-23 dacr initialization values bits name setting description 31?18 ba base address. so dacr0[31?16] = 0xff88, which places the starting address of the sdram accessible memory at 0xff88_0000. 17?16 ? reserved. don?t care. 15 re 0 0, which keeps auto-refresh disabled because registers are being set up at this time. 14 ? reserved. don?t care. 13?12 casl 01 indicates a delay of data 1 cycle after cas is asserted 11 ? reserved. don?t care. 10?8 cbm 010 command bit is pin 19 and bank selects are 20 and up. 7 ? reserved. don?t care. 6 imrs 0 indicates mrs command has not been initiated. 5?4 ps 10 16-bit port. bank 0 1 mbyte 512 kbyte 512 kbyte sdram component accessible memory bank 1 1 mbyte 512 kbyte 512 kbyte bank 2 1 mbyte 512 kbyte 512 kbyte bank 3 1 mbyte 512 kbyte 512 kbyte 7-22 mcf5249um motorola sdram example 7.4.4 dmr initialization in this example, again, only the second 512-kbyte block of each 1-mbyte space is accessed in each bank. in addition the sdram component is mapped only to readable and writable supervisor and user data. the dmrs have the following configuration. with this configuration, the dmr0 = 0x0074_0075, as described in table 7-24 . 3 ip 0 indicates precharge has not been initiated. 2 pm 1 indicates continuous page mode 1?0 ? reserved. don?t care. 31 18 17 16 field bam ? setting 00000000011101xx (hex) 0 0 7 4 15 9876543210 field ? wp ? c/i am sc sd uc ud v setting xxxxxxx0x1 1 1 0101 (hex) 0 0 7 5 figure 7-16 dmr0 register table 7-24 dmr0 initialization values bits name setting description 31?16 bam with bits 17 and 16 as don?t cares, bam = 0x0074, which leaves bank select bits and upper 512k select bits unmasked. bits 22 and 21 are set because they are used as bank selects; bit 20 is set because it controls the 1-mbyte boundary address. 15?9 ? reserved. don?t care. 8 wp 0 allow reads and writes 7? reserved 6 c/i 1 disable cpu space access 5 am 1 disable alternate master access 4 sc 1 disable supervisor code accesses 3 sd 0 enable supervisor data accesses 2 uc 1 disable user code accesses 1 ud 0 enable user data accesses 0 v 1 enable accesses. table 7-23 dacr initialization values bits name setting description sdram example motorola section 7 synchronous dram controller module 7-23 7.4.5 mode register initialization when dacr[imrs] is set, a bus cycle initializes the mode register. if the mode register setting is read on a[9:0] of the sdram on the first bus cycle, the bit settings on the corresponding mcf5249 address pins must be determined while being aware of masking requirements. table 7-25 lists the desired initialization setting: next, this information is mapped to an address to determine the hexadecimal value. table 7-25 mode register initialization mcf5249 pins sdram pins mode register initialization a22 ba1 0 a21 ba0 0 a20 a11 reserved 0 a19 command wb 0 a18 a9 opmode 0 a17 a8 opmode 0 a9 a7 a10 a6 casl 0 a11 a5 casl 0 a12 a4 casl 1 a13 a3 bt 0 a14 a2 bl 0 a15 a1 bl 0 a16 a0 bl 0 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field setting xxxxxxxxx 0000000 (hex)0000 1514131211109876543210 field v setting 0001000x xxxxxxxx (hex) 1000 figure 7-17 mode register mapping to mcf5249 a[31:0] 7-24 mcf5249um motorola sdram example although a[31:20] corresponds to the address programmed in dacr0, according to how dacr0 and dmr0 are initialized, bit 19 must be set to hit in the sdram. thus, before the mode register bit is set, dmr0[19] must be set to enable masking. 7.4.6 initialization code the following assembly code initializes the sdram example. power-up sequence: move.w #0x8012, d0//initialize dcr move.w d0, dcr move.l #0xff881220, d0 //initialize dacr0 move.l d0, dacr0 move.l #0x00740075, d0//initialize dmr0 move.l d0, dmr0 precharge sequence: move.l #0xff881228, d0//set dacr0[ip] move.l d0, dacr0 move.l #0xbeaddeed, d0//write to memory location to init. precharge move.l d0, 0xff880000 refresh sequence: move.l #0xff889220, d0//enable refresh bit in dacr0 move.l d0, dacr0 mode register initialization sequence: move.l #0x00600075, d0//mask bit 19 of address move.l d0, dmr0 move.l #0xff889260, d0//enable dacr0[imrs]; dacr0[re] remains set move.l d0, dacr0 move.l #0x00000000, d0//access sdram address to initialize mode register move.l d0, 0xff801000 move.l #0x00740075, d0//set up dmr again move.l d0, dmr0 motorola section 8 bus operation 8-1 section 8 bus operation this section describes bus functionality, the bus control signals, and the bus cycles provided for data-transfer operations. bus operation is defined for transfers initiated by the mcf5249 as a bus master and for transfers initiated by an alternate bus master. this section includes descriptions of the error conditions, bus arbitration, and the reset operation. 8.1 bus features 23 bit address bus 16 bit data bus 16 bit port size generates byte, word, longword, and line size transfers burst and burst-inhibited transfer support internal termination generation 8.2 bus and control signals although the timing of all of these signals is referenced to the bclk, it is not considered a bus signal. it is expected that the clock will be routed as needed to meet application requirements. table 8-1 summarizes the mcf5249 bus signals. a brief description of the function of each signal follows. note: an overbar indicates an active-low signal. 8.2.1 address bus the address bus a[23:1] provides the address of the byte or most significant byte of the word or longword being transferred.the address lines also serve as the dram address pins, providing multiplexed row and column address signals. a0 is not available on the address bus. as a result, the mcf5249 supports only 16-bit port size. table 8-1 mcf5249 bus signal summary signal name direction description a[23:1] out address bus rw /gpio9 out read-write control d[31:16] in/out data bus cs0 out chip select 0 cs1 /gpio1 out chip select 1/gpio oe /gpo40 out output enable 8-2 mcf5249um motorola bus and control signals 8.2.2 read/write control the read/write control line is shared with gpio9. the power-on reset function of rw /gpio9 is rw . this function can be programmed in the gpio-function register. see section 9.8 general purpose i/os for details. when function is rw , pin will indicate if bus cycle in progress is read or write. rw timing is same as address timing. 8.2.3 transfer acknowledge (ta) this active-low synchronous input signal indicates the successful completion of a requested data transfer operation. during mcf5249-initiated transfers, transfer acknowledge (ta) is an asynchronous input signal from the referenced slave device indicating completion of the transfer. the mcf5272 edge-detects and retimes the ta input. this means that an additional wait state may or may not be inserted. for example if the active chip select is used to immediately generate the ta input, one or two wait states may be inserted in the bus access. the ta signal function is not available after reset. it must be enabled by configuring the appropriate pin configuration register bits along with the value of cso r n[ws]. if ta is not used, it should either have a pullup resistor or be driven through gating logic that always sensures the input is inactive. ta should be negated on the negating edge of the active chip select. ta must always be negated before it can be recognized as asserted again. if held asserted into the following bus cycle, it has no effect and does not terminate the bus cycle. note: for the mcf5249 to accept the transfer as successful with a transfer acknowledge, tea must be negated throughout the transfer. ta is not used for termination during sdram accesses. 8.2.4 data bus the data bus d[31:16] is a bidirectional, non-multiplexed bus. data is latched by the mcf5249 on the rising bclk clock edge. when interfacing with external memory or peripherals, the data bus port width, wait states, and internal termination are initially defined. the port width for each chip-select and dram bank are user programmable. if none of the chip-selects, dram bank or sbc spaces match the address decode, the memory cycle will terminate with error. the table 8-2 reset port settings reset port size 16 bit reset cycle length internal termination, 15 wait cycles clock and reset signals motorola section 8 bus operation 8-3 data bus can transfer byte or word-sized data. all 16 bits of the data bus are driven during writes, regardless of port width or operand size. figure 8-1 connections for external memory port sizes 8.2.5 chip selects chip select cs1 is shared with gpio1 and chip select cs0 is not. power-on reset function of cs1 /gpio1 is cs1 . the function can be programmed in th e gpio-function register. see section 9.8 general purpose i/os for details. when the address decode matches one of the chip select spaces, the mcf5249 processor will pull low one of the chip selects to indicate external device access on its bus. there are also two dedicated chip selects (cs2 and cs3) used for the ide and/or smartmedia interface. 8.2.6 output enable output enable oe is shared with gpo40. power-on reset function of oe /gpo40 is oe . the function can be programmed in the gpio1-function register. see section 9.8 general purpose i/os on gpios for details. when function is oe , the mcf5249 will pull this pin low during any read cycle from a device selected by cs 0, cs 1, cs2 or cs3. 8.3 clock and reset signals these signals provide the external system interface for the mcf5249 (see table 8-2 ). processor external data bus d[31:24] d[23:16] 16-bit port memory byte 0 byte 1 byte 2 byte 3 8-bit port memory byte 0 driver with indeterminate values byte 1 byte 2 byte 3 8-4 mcf5249um motorola bus characteristics 8.3.1 reset in asserting rsti causes the mcf5249 processor to enter reset exception processing. when rsti is recognized, the data bus is tri-stated, and oe , cs0 , and cs1 are negated. refer to section 8.7 . 8.3.2 system bus clock output the bclk output signal is generated by the internal pll, and is the system bus clock output used as the bus timing reference by the external devices. bclk is always half the frequency of the processor clock. 8.4 bus characteristics the external bus operates at the same speed as the bus clock rate, where all bus operations are synchronous to the rising edge of bclk, and the bus control signal cs are synchronous to the falling edge of the bclk, which is shown in figure 8-2 . the bus characteristics may be somewhat different for interfacing with external dram. table 8-3 cf-bus signal summary signal name direction description rsti in reset in bclk out system bus clock output data transfer operation motorola section 8 bus operation 8-5 figure 8-2 signal relationship to bclk for non-dram access 8.5 data transfer operation data transfer between the mcf5249 processor and other devices involves the following four signals: 1. address bus (a[23:1]) 2. rw control signal 3. data bus (d[31:16]) 4. strobe signal (cs0 , cs1 , oe ) the address bus, write data, and all attribute signals make transition on the rising edge of bclk. the strobe signals cs0 , cs1 , oe make its transition on the falling edge of bclk. read data is latched into the mcf5249 on the rising edge of bclk. the mcf5249 bus supports byte, word, and longword operand transfers and uses a 16-bit data port. with the mcf5249, the port size of all memory must be programmed to 16 bits, the internal transfer termination must be enabled, and the number of wait states must be set for the external slave being accessed by programming the chip-select control registers (cscrs) and the dram controller control registers (dcrs). for more information on programming these registers, refer to , and . figure 8-1 shows the byte lanes that external chip-select memory and dram should be connected to and the sequential transfers that would occur for each memory if a longword was transferred to it. a 16-bit bclk output signals output control inputs t vo t ho t vo t ho t si t hi t vo = propagation delay of signal relative to bclk edge t ho = output hold time relative to bclk edge t si = required input setup time relative to bclk edge t hi = required input hold time relative to bclk edge 8-6 mcf5249um motorola data transfer operation memory should be connected to[31:16] of the mcf5249 data bus. for a longword transfer, the most significant word d[31:16] will be transferred on lane d[31:16], followed by the least significant word being transferred. 8.5.1 bus cycle execution when a bus cycle is initiated, the mcf5249 processor compares the address of that bus cycle with the base address and mask configurations programmed for various memory-mapped peripherals. these include sram0, sram1, system bus controller 1 and 2, chip selects 0 and 1 and dram block 0 and 1. if no match is found, the cycle will terminate in error. if a match is found for chip select 0 and 1, or dram block 0 and 1, the bus cycle will be executed on the external bus. chip select accesses follow timing diagrams given in this section. dram accesses are different. they are described in the section on the dram controller. figure 8-4 basic read bus cycle shows the type of access as a function of match in various memory space programming registers. basic operation of the mcf5249 bus is a three-clock bus cycle. during the first clock, the address is driven. csx is asserted at the falling edge of the clock to indicate that address and attributes are valid and stable. data and ta are sampled during the second clock of a bus-read cycle. ta is generated internally in the chip select module. during a read, the external device provides data and is sampled at the rising edge at the end of the second bus clock. this data is concurrent with ta, which is also sampled at the rising edge of the clock. during a write, the mcf5249 drives data from the rising clock edge at the end of the first clock to the rising clock edge at the end of the bus cycle. users can add wait states between the first and second clocks by delaying the assertion of ta . this refers to internal transfers only and not the write cycles. this is done by programming the relevant chip select registers. if ?0000? is programmed in the ws field of the relevant chip select register, a no wait cycle table 8-4 accesses by matches kram matches sbc 2 matches sbc 1 matches number of chip selects register matches number of dram controlle r register matches type of access yes any any any any on-chip sram no yes any any any sbc 2 no no yes none none sbc 0 no no no single none as defined by chip-select control register no no no none single as defined by dram control register no no no none none undefined all other combinations undefined data transfer operation motorola section 8 bus operation 8-7 results. if n is programmed in the ws field, n wait cycles will result. the last clock of the bus cycle uses what would be an idle clock between cycles to provide hold time for address and write data. figure 8-4 and figure 8-6 show the basic read and write operations. 8.5.2 read cycle the read cycle as shown in figure 8-4 , will occur if the wait cycle field (ws) in the chip select control register (csr) is programmed to value ?0000?. the cs low time is increased with n clocks if n is programmed into the ws field. during a read cycle, the mcf5249 receives data from memory or from a peripheral device. the read cycle flowchart is shown in figure 8-3 while the read cycle timing diagram is shown in figure 8-4 . figure 8-3 read cycle flowchart figure 8-4 basic read bus cycle mcf5249 1. set r/w to read 2. place address on a[23:1] 1. decode address and sele ct appropriate device 2. drive data on d[31:16] 3. cs unit asserts /ta (internal termination) or assert /ta externally for 1 bclk0 cycle (external termination). 1. sample /ta low and latch data 1. stop driving d[31:16] 1. start next cycle bclk a[23:1] r/w d[31:16] ta s0 s1 s2 s3 s4 s5 cs x oe read 8-8 mcf5249um motorola data transfer operation a basic read bus cycle has six states (s0?s5). the signal timing relationship in the constituent states of a basic read cycle is as follows: 8.5.3 write cycle the write cycle as shown in figure 8-6 , will occur if the wait cycle field (ws) in the chip select control register (csr) is programmed to value ?0000?. the cs low time is increased with n clocks if n is programmed into the ws field. during a write cycle, the mcf5249 sends data to the memory or to a peripheral device. the write cycle flowchart is shown in the following figure, while the write cycle timing diagram is shown in figure 8-6 . table 8-5 read cycle states state name description state 0 the read cycle is initiated in state 0 (s0). on the rising edge of bclk, the mcf5249 places a valid address on the address bus and drives r/w high, if it is not already high. state 1 the appropriate cs and oe are asserted on the falling edge of bclk. state 2 state 3 data is made available by the external device and is sampled on the rising edge of bclk with /ta asserted. if /ta not asserted before the rising edge of bclk at the end of the first clock cycle, the mcf5249 inserts wait states (full clock cycles) until /ta is asserted. if internal /ta is requested (auto-acknowledge enabled in the chip select control register, cscr) then /ta is generated internally by the chip select module. state 4 during state 4, /ta should be negated by the external device or if auto-acknowledge is enabled, negated internally by the chip select module. state 5 cs and oe are negated on the falling edge of stat e 5 (s5). the mcf5249 stops driving the address lines and r/w on the rising edge of bclk, terminating the read cycle. the external device must have its drive from the bus...? with ?the external device must stop driving the bus. the rising edge of bclk may be the start of state 0 for the next access cycle. note: the external device has a maximum of 1.5 bclk cycles after the start of s4 to three-state the data bus after data is sampled in s3 during a read cycle. this applies to basic read cycles and the last transfer of a burst. note: the mcf5249 would not drive out data for a minimum of two bclk cycles. however, another slave device may start driving the bus as soon as its chip select is asserted. chip select may be asserted at the beginning of s1, so bus drive must stop before the end of s0. under these conditions, data contention on the bus would not exist. data transfer operation motorola section 8 bus operation 8-9 figure 8-5 write cycle flowchart the description for the six states of a basic write cycle is as follows: figure 8-6 basic write bus cycle table 8-6 write cycle states state name description state 0 the write cycle is initiated in state 0 (s0). on the rising edge of bclk, the mcf5249 places a valid address on the address bus and drives r/w low, if it is not already low. state 1 the appropriate cs is asserted on the falling edge of bclk. state 2 the data bus is driven out of high impedance as data is placed on the bus on the rising edge of bclk. mcf5249 1. set r/w to write 2. place address on a[23:1] 3. drive data on d[31:16] 1. decode address 2. store data on d[31:16] 3. cs unit asserts /ta (internal termination) or assert /ta externally for 1 bclk0 cycle (external termination). 1. sample /ta low 2. tri-state data on d[31:16] 3. start next cycle system bclk a[23:1] r/w d[31:16] ta s0 s1 s2 s3 s4 s5 cs x write system 8-10 mcf5249um motorola data transfer operation 8.5.4 back-to-back bus cycles the mcf5249 can accommodate back-to-back bus cycles. the processor runs back-to-back bus cycles whenever possible. for example, when a longword read is started on a word-size bus, and burst read enable is disabled into the relevant chip select register, the processor will perform two word reads back to back. figure 7-9 shows a read, followed by a write that occurs back to back. a basic read and a write cycle are used to illustrate the back-to-back cycle. there is no restriction as to the type of operation to be placed back to back. the initiation of a back-to-back cycle is not user definable. figure 8-7 back-to-back bus cycles state 3 during state 3 (s3), the mcf5249 waits for a cycle termination signal (ta ). if ta is not asserted before the rising edge of bclk at the end of the first clock cycle, the mcf5249 inserts wait states (full clock cycles) until ta is asserted. ta is generated internally by the chip select module. if internal ta is requested (auto-acknowledge enabled in the chip select control register, cscr) then ta is generated internally by the chip select module. state 4 during state 4, ta should be negated by the external device or if auto-acknowledge is enabled, negated internally by the chip select module. state 5 cs is negated on the falling edge of bclk in state 5 (s5). the mcf5249 stops driving the address lines and r/w , terminating the write cycle. the data bus returns to high impedance on the rising edge of bclk. the rising edge of bclk may be the start of state 0 for the next access cycle. table 8-6 write cycle states state name description bclk a[31:0] r/w d[31:16] ta read s0 s1 s2 s3 s4 s5 s0 s1 s2 s3 s4 s5 write cs x oe data transfer operation motorola section 8 bus operation 8-11 8.5.5 burst cycles when burst read enable or burst write enable is asserted into the relevant chip select register, the mcf5249 will initiate burst cycles any time a transfer size is larger than the port size the mcf5249 is transferring to. a line transfer to a 16-bit port would constitute a burst cycle of eight words of data. the mcf5249 bus can support 3-2-2-2 burst cycles to maximize cache performance and optimize dma transfers. users can add wait states if desired by delaying termination of the cycle. through the chip select control registers, users can enable bursting on reads or bursting on writes or bursting on both reads and writes if desired. in the mcf5249, any chip select can be declared ?burst inhibited? by clearing the chip-select burst read-enable and burst write-enable bits for that region. if a line access is initiated to a region that is burst inhibited, back-to-back bus cycles will occur (see 8.5.4 back-to-back bus cycles ). 8.5.5.1 line transfers a line is defined as a 16-byte value, aligned in memory on 16-byte boundaries. although the line itself is aligned on 16-byte boundaries, the line access does not necessarily begin on the aligned address.therefore, the bus interface supports line transfers on multiple address boundaries. the allowable patterns during a line access are shown in table 8-7 . 8.5.5.2 line read bus cycles figure 8-9 shows a line access read with zero wait states. note: the bus cycle begins similar to a basic read bus cycle with the first data transfer being sampled on the rising edge of s4. however, also notice that the next pipelined burst data is sampled one cycle later on the rising edge of s6. each subsequent pipelined data burst will be single cycle until the last cycle which can be held for a maximum of 2 bclk past the ta assertion. cs and oe remain asserted throughout the burst transfer. figure 8-8 shows a line access read with one wait state. wait states can be programmed in the chip select control register (cscrs) to give the peripheral or memory more time to return read data. this figure follows the same execution as a zero-wait state read burst with the exception of an added wait state. table 8-7 allowable line access patterns addr[3:2] longword accesses 00 0 - 4 - 8 - c 01 4 - 8 - c - 0 10 8 - c - 0 - 4 11 c - 0 - 4 - 8 8-12 mcf5249um motorola data transfer operation figure 8-8 line read burst (one wait cycle) figure 8-9 shows a line read burst with no wait cycles. in this example, the external device executes a basic read cycle while determining that a line is being transferred. figure 8-9 line read burst (no wait cycles) 8.5.5.3 line write bus cycles figure 8-11 shows a line access write with zero wait states. note: the bus cycle begins similar to a basic write bus cycle with data being driven one clock after the address. also notice that the next pipelined burst data is driven one cycle after the write data has been registered (on the rising edge of s6). each subsequent pipelined write data burst will be a single cycle. cs remains asserted throughout the burst transfer. data transfer operation motorola section 8 bus operation 8-13 figure 8-10 line write burst (no wait cycles) the following figure shows a burst inhibited line read. figure 8-11 line read burst-inhibited figure 8-12 shows a line burst write with one state insertion. 8-14 mcf5249um motorola misaligned operands figure 8-12 line write burst with one wait state the following figure shows a burst-inhibited line write. figure 8-13 line write burst-inhibited 8.6 misaligned operands all mcf5249 data formats can be located in memory on any byte boundary. a byte operand is properly aligned at any address; a word operand is misaligned at an odd address; and a longword is misaligned at an address that is not evenly divisible by four. unlike opcodes, because operands can reside at any byte boundary, they are allowed to be misaligned. although the mcf5249 does not enforce any alignment restrictions for data operands (including program counter (pc) relative data addressing), some performance degradation occurs when additional bus cycles are required for longword or word operands that are misaligned. for maximum performance, data items should be aligned on their natural boundaries. reset operation motorola section 8 bus operation 8-15 all instruction words and extension words (opcodes) must reside on word boundaries. an address error exception will occur with any attempt to prefetch an instruction word at an odd address. the mcf5249 converts misaligned operand accesses that are noncachable to a sequence of aligned accesses. figure 8-14 illustrates the transfer of a longword operand from a byte address to a 32-bit port, requiring more than one bus cycle. the slave device supplies the byte and acknowledges the data transfer. the next two bytes are transferred during the second cycle. during the third cycle, the byte offset is now $0; the port supplies the final byte and the operation is complete. figure 8-15 is similar to the example illustrated in figure 8-14 except that the operand is word-sized and the transfer requires only two bus cycles. figure 8-14 misaligned longword transfer figure 8-15 misaligned word transfer 8.7 reset operation the mcf5249 processor supports one type of reset which resets the entire mcf5249: the external master reset input (rsti ). to perform a master reset, an external device asserts the reset input pin (rsti ). when power is applied to the system, external circuitry should assert rsti for a minimum of 16 clkin cycles after vcc is within tolerance. figure 8-16 is a functional timing diagram of the master reset operation, illustrating relationships among v cc , rsti , mode selects, and bus signals. the crystal oscillation on crin, crout must be stable by the time v cc reaches the minimum operating specification. the crystal should start oscillating as v cc is ramped up to clear out contention internal to the mcf5249 processor caused by the random states of internal flip-flops on power up. rsti is internally synchronized for two clkin cycles before being used and must meet the specified setup and hold times in relationship to crout to be recognized. transfer 1 transfer 2 transfer 3 ? ? op 0 op 3 ? ? ? op 2 ? ? op 1 ? 31 24 23 16 15 8 70 transfer 1 transfer 2 ? op 0 ? ? ? ? op 1 ? 31 24 23 16 15 8 70 8-16 mcf5249um motorola reset operation figure 8-16 master reset timing during the master reset period, the data bus is being three-stated, the address bus is driven to any value, and all other bus signals are driven to their negated state. once rsti negates, the bus stays in this state until the coldfire core begins the first bus cycle for reset exception processing. a master reset causes any bus cycle (including dram refresh cycle) to terminate. in addition, master reset initializes registers appropriately for a reset exception. at power-on reset, cs0 is configured to address the boot rom. boot rom configuration is hard-wired inside the mcf5249 configuration is summarized in table table 8-8 . 8.7.1 software watchdog reset the software watchdog reset is performed anytime the executing software does not provide the correct write data sequence with the enable-control bit set. this reset helps prevent runaway software or nonterminated bus cycles. figure 8-17 is a functional timing diagram of the software watchdog reset operation, illustrating relationships among rsto and bus signals. table 8-8 power-on reset configuration for cs0 port size 16 bits cycle type internal termination, 15 wait cycles burst inhibit asserted for both read and write cycles vcc rsti clkin d[31:16] sdras , sdcas cs , oe >16 clkin cycles sdwe , bclke a[23:1], rw reset operation motorola section 8 bus operation 8-17 figure 8-17 software watchdog reset timing during the software watchdog reset period, all signals that can be are driven to a high-impedance state and all those that cannot are driven to their negated states. once rsto negates, all bus signals continue to remain in a high-impedance state until the coldfire core begins the first bus cycle for reset exception processing. vcc rsti data[7:0] bclk bus signals = 16 bclk cycles >= 22 bclk cycles rsto 8-# mcf5249um motorola notes motorola section 9 system integration module 9-1 section 9 system integration module 9.1 sim introduction this section describes the operation and programming model of the system integration module (sim) registers, including the interrupt controller and system-protection functions for the mcf5249. the sim provides overall control of the internal and external buses and serves as the interface between the coldfire core processor and the internal peripherals or external devices. the sim also configures the general purpose input/output and enables the cpu stop instruction. 9.1.1 sim features module base address register (mbar and mbar2) ? base address location of all internal peripherals and sim resources ? address space masking to internal peripherals and sim resources interrupt controller ? two interrupt controllers ? programmable interrupt level (1-7) for internal peripheral interrupts system protection and reset status ? reset status to indicate cause of last reset ? software watchdog timer with optional secondary bus monitor functionality bus arbitration control register (mpark) ? enables display of internal accesses on the external bus for debug general purpose input/output registers ? defines general-purpose inputs and outputs ? edge interrupt triggers on general-purpose i/os, 0 to 7 software interrupts ? allow programmer to make interrupt pending under software control 9.2 programming model 9.2.1 sim register memory map table 9-1 shows the memory map of all the sim registers. the internal registers in the sim are memory-mapped registers offset from the mbar or mbar2 address pointers. the following list addresses some issues regarding the programming model table: the module base address registers are accessed in supervisor mode only using the movec instruction. the mbar and mbar2 are accessible using the debug module as read/write registers. see for more details. 9-2 mcf5249um motorola programming model table 9-1 mbar register addresses address name size (bytes ) description cpu + $c0f mbar 4 module base address register cpu + $c0e mbar2 4 module base address register 2 table 9-2 sim memory map address description 0123 mbar + $000 system control reg rsr sypcr swivr swsr mbar + $004 reserved mbar + $008 reserved mbar + $00c bus master control reg mpark reserved mbar + $010 ? reserved mbar + $014 ? mbar + $018 ? mbar + $01c ? mbar + $020 ? mbar + $024 ? mbar + $028 ? mbar + $02c ? mbar + $030 ? mbar + $034 ? mbar + $038 ? mbar + $03c ? mbar + $040 primary interrupt pending reg ipr mbar + $044 primary interrupt mask reg imr mbar + $04c primary interrupt control reg icr0 icr1 icr2 icr3 mbar + $050 primary interrupt control reg icr4 icr5 icr6 icr7 mbar + $054 primary interrupt control reg icr8 icr9 icr10 icr11 mbar2 + $000 gpio 0-31 input reg gpio-read (read only) mbar2 + $004 gpio 0-31 output reg gpio-out mbar2 + $008 gpio 0-31 output enable reg gpio-enable mbar2 + $00c gpio 0-31 function select gpio-function mbar + $0ac device id reg mbar2 + $0b0 gpio 32-63 inpu t reg gpio1-read (read only) mbar2 + $0b4 gpio 32-63 output reg gpio1-out sim programming and configuration motorola section 9 system integration module 9-3 9.3 sim programming and configuration 9.3.1 module base address registers the base address of all internal peripherals is determined by the mbar and mbar2 registers. the mbar and mbar2 are 32-bit write-only supervisor control register that physically reside in the sim. they are accessed in the cpu address spaces $c0f and $c0e using the movec instruction. refer to the coldfire family programmer?s reference manual rev. 1.0 for use of movec instruction. the mbar and mbar2 can be read when in debug mode using background debug commands. at system reset, the mbar valid bits (mbar[0], mbar2[0]) are cleared to prevent incorrect reference to resources before the mbar or mbar2 are written. the remainder of the mbar or mbar2 bits are uninitialized. to access the mbar and mbar2 peripherals, users should write mbar and mbar2 with the appropriate base address and set the valid bit after system reset. the mbar2 base address defines a single relocatable memory block along 1024-mbyte boundaries. if the mbar2 valid bit is set, the base address field is compared to the upper two bits of the full 32-bit internal address to determine if an mbar2 peripheral is being accessed. any processor bus access is first compared for sram match (rambar registers), then it is compared against mbar and mbar2. if no match is found in any of these registers, the cycle will be mapped to the chip select and sdram units. table 9-3 shows the bits in the module base address register (mbar), and table 9-5 shows the bits in the mbar2. address description 0123 mbar2 + $0b8 gpio 32-63 output enable reg gpio1-enable mbar2 + $0bc gpio 32-63 function select gpio1-function mbar2 + $140 secondary interrupts 0-7 priority intpri1 mbar2 + $144 secondary interrupts 8-15 priority intpri2 mbar2 + $148 secondary interrupts 16-23 priority intpri3 mbar2 + $14c secondary interrupts 24-31 priority intpri4 mbar2 + $150 secondary interrupts 32-39 priority intpri5 mbar2 + $154 secondary interrupts 40-47 priority intpri6 mbar2 + $158 secondary interrupts 48-55 priority intpri7 mbar2 + $15c secondary interrupts 56-63 priority intpri8 mbar2 + $164 spurious secondary interrupt vector spurvec mbar2 + $168 secondary interrupt base vector register intbase mbar2 + $198 software interrupts and interrupt monitor extraint table 9-2 sim memory map 9-4 mcf5249um motorola sim programming and configuration table 9-3 module base address register (mbar) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field ba31 ba30 ba29 ba28 ba27 ba26 ba25 ba24 ba23 ba22 ba21 ba20 ba19 ba18 ba17 ba16 reset---------------- r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w bits1514131211109876543210 field ba15 ba14 ba13 ba12 wp am c/i sc sd uc ud v reset---------------0 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w mbar2bas + 180 table 9-4 module base address bit descriptions bit name description ba[31:12] the base address field defines the base address for a minimum 4-kbyte address range. wp attribute space mask. the write protect bit is the mask bit for write cycles in the mbar-mapped register address range. 0 = module address range is read/write 1 = module address range is read only am attribute space mask. am?alternate master mask when am = 0 and an alternate master actually accesses the mbar-mapped registers; bits sc, sd, uc, and ud (mbar[4:1]) are ?don?t cares? in the address decoding. 0 = alternate master access allowed 1 = alternate master access masked sc attribute space mask. mask supervisor code space in mbar address range 0 = supervisor code access allowed 1 = supervisor code access masked sd attribute space mask. mask supervisor data space in mbar address range 0 = supervisor data access allowed 1 = supervisor data access masked c/i attribute space mask. mask cpu space and interrupt acknowledge cycle 0 = iack cycle mapped to mbar space 1 = iack cycle not responded to by mbar peripherals uc attribute space mask. mask user code space in mbar address range 0 = user code access allowed 1 = user code access masked ud attribute space mask. mask user data space in mbar address range 0 = user data space access allowed 1 = user data space access masked sim programming and configuration motorola section 9 system integration module 9-5 the following example shows how to set the mbar to location $10000000 using the d0 register. a ?1? in the least significant bit validates the mbar location. this example assumes that all accesses are valid: move.1 #$10000001,do movec do,mbar 9.3.2 device id the deviceid register is a read only register that allows the software to determine which hardware it is running on. the register contains the part number in the upper 24 bits, the mask revision number in the lower 8 bits, and is read as 0x005448rr, where rr is the revision number. this register allows developers the flexibility to write code to run on more than one device. the revision number allows developers to distinguish between different mask versions that may have minor changes or v this bit defines when the base address is valid: 0 = mbar address space not visible by cpu 1 = mbar address space visible by cpu table 9-5 second module base address register (mbar2) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 fieldba31ba30-------------- reset00-------------- r/w r/w r/w bits1514131211109876543210 field ls7 ls6 ls5 ls4 ls3 ls2 ls1 v reset-------- 00000000 r/w r/w r/w r/w r/w r/w r/w r/w r/w table 9-6 second module base address bit descriptions bit name description ba[31:30] the base address field defines the base address for a 1024-mbyte address range. if v-bit in mbar2 is set, address range base address to baseaddress + $3fff ffff are mapped to mbar2 space, and cannot be used for mbar, sdram or chip select. ls[7:1] if interrupts both ?primary? and the ?secondary? interrupt controller have interrupt level 7 pending, bit ls7 determines which interrupt controller gets priority. if this bit is cleared, the primary interrupt controller gets priority. if this bit is set, the secondary interrupt controller gets priority. there are 7 lsn bits, one for each interrupt level. v the valid bit defines if the cpu can access the mbar2 mapped peripherals 0 = mbar2 address space not visible by cpu. 1 = mbar2 address space visible by cpu table 9-4 module base address bit descriptions bit name description 9-6 mcf5249um motorola interrupt interface bug fixes. for example, developers may want to distribute a single code image or library for use on different revisions of the silicon. 9.3.3 interrupt controller for legacy reasons, there are two interrupt controllers on the mcf5249. 1. the primary interrupt controller offers the same functionality as the mcf5307 interrupt controller. 2. the secondary interrupt controller offers additional interrupts for on-chip peripheral devices that are not present in the mcf5307. the primary interrupt controller is centralized, and services the following: software watchdog timer timer modules i 2 c 1 module uart modules dma module qspi module the secondary interrupt controller is decentralized, and services the following: gpio interrupts audio interface module memorystick/sd module ad convertor module i 2 c 2 module 9.4 interrupt interface 9.4.1 primary controller interrupt registers primary internal interrupt sources have their own interrupt control registers icr[11:0], ipr, and imr. table 9-7 gives the location and description of each icr. table 9-7 deviceid register (deviceid) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field part number reset - - - - - - - --------- r/w read only bits 1514131211109876543210 field part number mask revision reset - - - - - - - --------0 r/w read only addr mbar+2 0xac interrupt interface motorola section 9 system integration module 9-7 primary interrupts are programmed to a level and priority. all primary interrupts have a unique interrupt control register (icr). there are 28 possible priority levels, encompassing primary interrupts. the bits of the icr are shown in table 9-9 . table 9-8 primary interrupt control register memory map address name width description reset value access mbar + $04c icr0 8 swt $00 r/w mbar + $04d icr1 8 timer 0 $00 r/w mbar + $04e icr2 8 timer 1 $00 r/w mbar + $04f icr3 8 i 2 c $00 r/w mbar + $050 icr4 8 uart 1 $00 r/w mbar + $051 icr5 8 uart 2 $00 r/w mbar + $052 icr6 8 dma 0 $00 r/w mbar + $053 icr7 8 dma 1 $00 r/w mbar + $054 icr8 8 dma 2 $00 r/w mbar + $055 icr9 8 dma 3 $00 r/w mbar + $056 icr10 8 qspi $00 r/w mbar + $057 icr11 8 reserved ? ? table 9-9 interrupt control register (icr) bits76543210 field avec - - il[2] il[1] il[0] ip[1] ip[0] reset0 - - 00000 r/w r/w r/w r/w r/w r/w r/w table 9-10 interrupt control bit descriptions bit name description avec the autovector enable bit determines whether the interrupt-acknowledge cycle input (for the internal interrupt level indicated in il[2:0] for each interrupt) requires an autovector response. 0 = interrupting source returns vector during interrupt-acknowledge cycle 1 = sim generates auto vector during interrupt acknowledge cycle il[2:0] the interrupt level bits indicate the interrupt level assigned to each interrupt input. ip[1:0] the interrupt priority bits indicate the interrupt priority within the interrupt level assignment. table 9-11 shows the priority levels associated with the ip contents. 9-8 mcf5249um motorola interrupt interface table 9-12 shows all possible primary source priority schemes for the mcf5249. the interrupt source in this table can be any internal interrupt source programmed to the given level and priority. for example, assume that two internal interrupt sources were programmed to il[2:0] =110, one having a priority of ip[1:0] = 01 and one having a priority of ip[1:0] = 10. if both assert an interrupt request at the same time, the order of servicing would occur as follows: 1. internal module with il[2:0] =110 and ip[1:0] = 10 would be serviced first 2. internal module with il[2:0] = 110 and ip[1:0] = 01 would be serviced last table 9-11 interrupt priority assignment ip[1:0] priority 00 lower 01 low 10 high 11 higher table 9-12 interrupt priority scheme interrupt level internal module icr reg interrupt source il[2:0] ip[1] ip[0] 7 111 1 1 internal module 7 111 1 0 internal module 7 111 0 1 internal module 7 111 0 0 internal module 6 110 1 1 internal module 6 110 1 0 internal module 6 110 0 1 internal module 6 110 0 0 internal module 5 101 1 1 internal module 5 101 1 0 internal module 5 101 0 1 internal module 5 101 0 0 internal module 4 100 1 1 internal module 4 100 1 0 internal module 4 100 0 1 internal module 4 100 0 0 internal module interrupt interface motorola section 9 system integration module 9-9 note: multiple internal modules shall not be assigned to the same interrupt level and same interrupt priority when configuring the icr registers. this can cause erratic chip behavior. 9.4.1.1 interrupt mask register the imr register is used to mask both internal and external interrupt sources from occurring. interrupt level internal module icr reg interrupt source il[2:0] ip[1] ip[0] 3 011 1 1 internal module 3 011 1 0 internal module 3 011 0 1 internal module 3 011 0 0 internal module 2 010 1 1 internal module 2 010 1 0 internal module 2 010 0 1 internal module 2 010 0 0 internal module 1 001 1 1 internal module 1 001 1 0 internal module 1 001 0 1 internal module 1 001 0 0 internal module table 9-13 interrupt mask register (imr) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field qspi dma 3 dma 2 reset ? ? ? ? ? ? ? ? ? ? ? ? ? 1 1 1 r/w r/w r/w r/w bits151413121110 9 8 76543 2 1 0 field dma 1 dma 0 uart 1 uart 0 i 2 ctimer1timer0swt ? ? ? ? ? ? ? ? reset11111 1 1 1 11111 1 1 ? r/w r/w address mbar (0 x 44) table 9-12 interrupt priority scheme 9-10 mcf5249um motorola interrupt interface 9.4.1.2 interrupt pending register the ipr makes visible the interrupt sources that have an interrupt pending. table 9-14 interrupt mask bit descriptions bit name description imr[17:8] each interrupt mask bit corresponds to an interrupt source defined in the interrupt control register (icr). an interrupt is masked by setting the corresponding bit in the imr. when a masked interrupt occurs, the corresponding bit in the ipr is still set, regardless of the setting of the imr bit, but no interrupt request is passed to the core processor. at system reset, all defined bits are initialized high, thereby masking all interrupts. the proper procedure for masking interrupt sources is to first set the core?s status register interrupt mask level to the level of the source being masked in the imr. then, the imr bit can be masked. an interrupt can be masked by setting the corresponding bit in the imr and enable an interrupt by clearing the corresponding bit in the imr. when a masked interrupt occurs, the corresponding bit in the ipr is still set, regardless of the setting of the imr bit, but no interrupt request is passed to the core processor. res[7:1] reserved. table 9-15 interrupt pending register (ipr) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field qspi dma 3 dma 2 reset ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field dma 1 dma 0 uart 1 uart 0 i 2 ctimer1timer0swt ? ? ? ? ? ? ? ? reset ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? mbar (0x40) table 9-16 interrupt pending bit descriptions bit name description ipr[18:8] each interrupt pending bit corresponds to an interrupt source defined by the interrupt control register. at every clock this register samples the signal generated by the interrupting source. the corresponding bit in this register reflects the state of the interrupt signal even if the corresponding mask bit were set. the ipr is a read-only longword register. 0 = the corresponding interrupt source does not have an interrupt pending 1 = the corresponding interrupt source has an interrupt pending res[7:1] reserved. interrupt interface motorola section 9 system integration module 9-11 9.4.2 secondary interrup t controller registers a second interrupt controller was added to the mcf5249. the secondary controller serves 64 interrupt sources with programmable interrupt levels. all 64 interrupts are auto-vectored. interrupt pending registers and interrupt mask registers are decentralized, and available in the modules that own the interrupts. 9.4.2.1 interrupt level selection the interrupt level, intpri[1:8], of the 64 interrupts serviced by the secondary interrupt controller can be programmed for every interrupt separately. every interrupt is given a 4-bit field in one of the interrupt priority register. this 4-bit field controls level setting for the interrupt. values 1-7 correspond with coldfire interrupt priorities. value 0 is off. table 9-17 secondary interrupt controller registers memory map address name width description reset value access mbar2 + $140 intpri1 32 interrupts 0-7 priority $00 r/w mbar2 + $144 intpri2 32 interrupts 8-15 priority $00 r/w mbar2 + $148 intpri3 32 interrupts 16-23 priority $00 r/w mbar2 + $14c intpri4 32 interrupts 24-31 priority $00 r/w mbar2 + $150 intpri5 32 interrupts 32-39 priority $00 r/w mbar2 + $154 intpri6 32 interrupts 40-47 priority $00 r/w mbar2 + $158 intpri7 32 interrupts 48-55 priority $00 r/w mbar2 + $15c intpri8 32 interrupts 56-63 priority $00 r/w mbar2 + $16b intbase 8 interrupt base vector $00 r/w mbar2 + $167 spurvec 8 spurious vector $00 r/w table 9-18 secondary interrupt level programming bit assignment address name bit 31-28 bit 27-24 bit 23-20 bit 19-16 bit 15-12 bit 11-8 bit 7-4 bit 3-0 mbar2 + $140intpri1int7int6int5int4int3int2int1int0 mbar2 + $144 intpri2 int15 int14 int13 int12 int11 int10 int9 int8 mbar2 + $148 intpri3 int23 int22 int21 int20 int19 int18 int17 int16 mbar2 + $14c intpri4 int31 int30 int29 int28 int27 int26 int25 int24 mbar2 + $150 intpri5 int39 int38 int37 int36 int35 int34 int33 int32 mbar2 + $154 intpri6 int47 int46 int45 int44 int43 int42 int41 int40 mbar2 + $158 intpri7 int55 int54 int53 int52 int51 int50 int49 int48 mbar2 + $15c intpri8 int63 int62 int61 int60 int59 int58 int57 int56 9-12 mcf5249um motorola interrupt interface 9.4.2.2 interrupt vector generation all secondary interrupts are autovectored. the vector number for interrupt 0 is given by register intbase. the vector numbers for the other interrupts are offset from this number. vector number for interrupt 23 is e.g. intbase + 23 . the secondary interrupt controller will generate vector numbers intbase to intbase + 63 for its 64 interrupts. 9.4.2.3 spurious vector register the spurvec register contains the interrupt vector number that is fed when a spurious interrupt event occurs on the secondary interrupt controller. a spurious interrupt occurs when a pending interrupt causes the coldfire processor to feed an interrupt vector, but before the interrupt vector can be fed, the pending interrupt disappeared. 9.4.2.4 secondary interrupt sources the 64 secondary interrupts are used by modules as detailed in table 9-22 . table 9-19 intbase register description bits 7 6 5 4 3 2 1 0 field base[7] base[6] base[5] base[4] base[3] base[2] base[1] base[0] reset00000000 r/w r/w r/w r/w r/w r/w r/w r/w r/w addr mbar2 + $16 b table 9-20 intbase bit descriptions bit name description base[7:0] this is the 8-bit interrupt vector for interrupt 0. vector numbers for other interrupts are obtained by adding the interrupt number to base. e.g. interrupt 23 vector is base + 23 . table 9-21 spurvec register description bits 7 6 5 4 3 2 1 0 field spurvec[7] spurvec[6] spurvec[5] spurvec[4 ] spurvec[3] spurvec[2] spurvec[1] spurvec[0] reset ? ? ? ? ? ? ? ? r/w r/w r/w r/w r/w r/w r/w r/w r/w addr mbar2 + $167 table 9-22 secondary interrupt sources interrupt interrupt name module description 63 a/d a/d a to d convertor 62 iic2 iic2 iic2 interrupt 61 ipaddresserror sim ip address error cycle interrupt b interrupt interface motorola section 9 system integration module 9-13 60 flashinter sd/memorystick interrupt 59 flashinter sd/memorystick interrupt 58 flashinter sd/memorystick interrupt 57 flashinter sd/memorystick interrupt 56 cdromnewblock audio cd-rom new block interrupt 55 cdromilsync audio cd-rom ilsync interrupt 54 cdromnosync audio cd-rom nosync interrupt 53 cdromcrcerr audio cd-rom crc error interrupt 52 51 50 softint3 auxint software interrupt 3 49 softint2 auxint software interrupt 2 48 softint1 auxint software interrupt 1 47 softint0 auxint software interrupt 0 46 45 44 43 42 41 40 39 gpi7 sim gpio interrupt a 38 gpi6 sim gpio interrupt 37 gpi5 sim gpio interrupt 36 gpi4 sim gpio interrupt 35 gpi3 sim gpio interrupt 34 gpi2 sim gpio interrupt 33 gpi1 sim gpio interrupt 32 gpi0 sim gpio interrupt 31 iis1txunov audio iis1 transmit fifo under / over 30 iis1txresyn audio iis1 transmit fifo resync 29 iis2txunov audio iis2 transmit fifo under / over 28 iis2txresyn audio iis2 transmit fifo resync 27 ebutxunov audio iec958 transmit fifo under / over 26 ebutxresyn audio iec958 transmit fifo resync 25 iec958-1 cnew audio iec958-1 receives new c control channel frame 24 iec958-1 val nogood audio iec958 validity flag no good 23 iec958-1 parity or symbol error audio iec958 receiver 1 bit or symbol error 22 pdir3unov audio processor data in 3 under/over 21 uchantxempty audio u channel transmit register is empty 20 uchantxunder audio u channel transmit register underrun 19 uchantx nextfirst audio u channel transmit register next byte will be first 18 iec958-1 u/q buffer attention audio iec 958 -1 u/q channel buffer full interrupt 17 iec958-2 cnew audio new c-channel received on iec958-2 table 9-22 secondary interrupt sources interrupt interrupt name module description 9-14 mcf5249um motorola interrupt interface 16 iec958-2 valnogood audio validity flag not good on iec958-2 15 iec958-2 parity error or symbol error audio iec958-2 receiver parity error or symbol error 14 iec958-2 u/q buffer attention audio iec958-2 u/q channel buffer full interrupt 13 u1chanrcvover q1chanoverrun uq1chanerr audio iec958 receiver 1u/q channel error 12 pdir1unov audio processor data in 1 under / over 11 pdir1resyn audio processor data in 1 resync 10 pdir2unov audio processor data in 2 under / over 9 pdir2resyn audio processor data in 2 resync 8 audiotick audio ?tick? interrupt 7 u2chanrcvover q2chanoverrun uq2chanerr audio iec 958 receiver 2 u/q channel error 6 pdir3 resync audio processor data in 3 resync 5 pdir3 full audio processor data in 3 full 4 iis1txempty audio iis1 transmit fifo empty 3 iis2txempty audio iis2 transmit fifo empty 2 ebutxempty audio ebu transmit fifo empty 1 pdir2 full audio processor data in 2 full 0 pdir1 full audio processor data in 1 full a. set the gpio_function register bit to 1 or 0 for interrupts, as applicable. b. this interrupt triggers if an ip bus peripheral generates a transfer error acknowledge interrupt on the ip bus. this interrupt is used for s/w debug and should not normally be generated. this interrupt maybe generated if for example one of the audio fifo 's is accessed in byte or word mode. for interrupt 57-60, see table 9-23 . table 9-23 flashmedia interrupt interface flashmediaintstat flashmediainten flashmediaintclear bits int name meaning reset interrupt associated interrupt 0 shiftbusy1fall interrupt set on falling edge of shift_busy_1 intclear 60 1 shiftbusy1rise interrupt set on rising edge of shift_busy_1 intclear 60 2 intlevel1fall interrupt set on falling edge of int_level_1 intclear 60 3 intlevel1rise interrupt set on rising edge of int_level_1 intclear 60 4 shiftbusy2fall interrupt set on falling edge of shift_busy_2 intclear 59 5 shiftbusy2rise interrupt set on rising edge of shift_busy_2 intclear 59 6 intlevel2fall interrupt set on falling edge of int_level_2 intclear 59 7 intlevel2rise interrupt set on rising edge of int_level_2 intclear 59 8 rcv1full interrupt set if receive buffer reg 1 full read data 58 9 tx1empty interrupt set if transmit buffer reg 1 empty write data 58 table 9-22 secondary interrupt sources interrupt interrupt name module description system protection and reset status motorola section 9 system integration module 9-15 9.4.3 software interrupts the mcf5249 supports four software interrupts. these interrupts are activated by writing a ?1? to an extraint register bit. when active, the interrupts can generate a normal interrupt exception to the coldfire processor. the interrupt exception is only generated if the corresponding level register interrupt mask is higher than the current processor interrupt mask. table 9-24 extraint register descriptions note: bits 7-4 of the register return on read the value of the software interrupts 0-3. when written zero, the value of the corr esponding software interrupt will not change. when written one, the corresponding software interrupt is set to 1. note: bits 3-0 of the register return on read the value of software interrupts 0-3. when written zero, the value of the correspo nding software interrupt will not change. when written one, the corresponding software interrupt is set to 0. 9.5 system protection and reset status 9.5.1 reset status register the rsr contains a bit for each reset source to the sim. a bit set to 1 indicates the last type of reset that occurred. the rsr is updated by the reset control logic on completion of the reset operation. only one bit will be set at any given time in the rsr. the register reflects the cause of the most recent reset. if a reset occurs and the user failed to clear this register, reset control logic will clear all bits and set the appropriate bit to indicate the current cause of reset. the rsr programming model is illustrated as follows. the reset status register (rsr) is an 8-bit supervisor read-write register. 10 rcv2full interrupt set if receive buffer reg 2 full read data 57 11 tx2empty interrupt set if transmit buffer reg 2 empty write data 57 extraint mbar2 + 198 bit field name access description int no note 3,7 softint3 r read softint3 value 50 1,2 2,6 softint2 r read softint2 value 49 1,2 1,5 softint1 r read softint1 value 48 1,2 0,4 softint0 r read softint0 value 47 1,2 7 softint3_set w write one to this bit to set softint3 50 1 6 softint2_set w write one to this bit to set softint2 49 1 5 softint1_set w write one to this bit to set softint1 48 1 4 softint0_set w write one to this bit to set softint0 47 1 3 softint3_clr w write one to this bit to clear softint3 50 2 2 softint2_clr w write one to this bit to clear softint2 49 2 1 softint1_clr w write one to this bit to clear softint1 48 2 0 softint0_clr w write one to this bit to clear softint0 47 2 table 9-23 flashmedia interrupt interface flashmediaintstat flashmediainten flashmediaintclear bits int name meaning reset interrupt associated interrupt 9-16 mcf5249um motorola system protection and reset status 9.5.2 software watchdog timer the swt prevents system lockup should the software become trapped in loops with no controlled exit. the swt can be enabled or disabled using the swe bit in the sypcr. if enabled, the swt requires the execution of a software watchdog servicing sequence periodically. if this periodic servicing action does not occur, the swt times out resulting in a swt irq or hardware reset, as programmed by the swri bit in the sypcr. if the swt times out and software watchdog transfer acknowledge enable (swta = sypcr[2]) bit is set in the system protection control register, the swt irq will assert. if after another timeout and the swt iack cycle has not occurred, the swt ta signal will assert in an attempt to terminate the bus cycle and allow iack cycle to proceed. the setting of the swtaval flag bit (sypcr[1]) in the system protection control register indicates that the swt ta signal was asserted. the swta function when terminating a locked bus is shown in figure 9-1 . table 9-25 reset status register (rsr) bits 7 6 5 4 3 2 1 0 fieldhrst?swtr????? reset10000000 r/w r/w r/w r/w addr mbar + $(0x00) table 9-26 reset status bit descriptions bit name description hrst for the hardware or system reset, a 1 = an external device driving rsti caused the last reset. assertion of reset by an external device causes the core processor to take a reset exception. all registers in internal peripherals and the sim are reset. swtr for the software watchdog timer reset, a 1 = the last reset was caused by the software watchdog timer. if swri in the sypcr is set and the software watchdog timer times out, a hardware reset occurs. system protection and reset status motorola section 9 system integration module 9-17 figure 9-1 mcf5249 unterminated access recovery when the swt times out and swri register bit is programmed for a software reset, an internal reset will be asserted, and the swtr register bit will be set in the rsr. to prevent swt from interrupting or resetting, users must service the swsr register. the swt service sequence consists of the following steps: 1. write $55 to swsr 2. write $aa to the swsr both writes must occur in the order listed prior to the swt timeout, but any number of instructions or accesses to the swsr can be executed between the two writes. this order allows interrupts and exceptions to occur, if necessary, between the two writes. caution should be exercised when changing system protection control register (sypcr) values after the software watchdog timer (swt) has been enabled with the setting of the swe register bit, because it is difficult to determine the state of the swt while the timer is running. the swp and swt[1:0] bits in sypcr determine the swt timeout period. the countdown value determined by the swp and swt[1:0] bits is constantly compared with that specified by these bits. therefore, altering the contents of the swp and swt[1:0] bits improperly will result in unpredictable processor behavior. the following steps must be taken in order to change one of these values in the sypcr: code enables swt interrupt and 1. swt times-out due to un-terminated bus 2. unable to service swt interrupt due to ?hung? bus cycle. wait another swt timeout before setting swta. swt timeout swt timeout swtaval 2 swt ta 1 swt irq 1 swta functionality by writing sypcr (bit 1 in sypcr) swt iack cycle code in swt interrupt handler polls the swtaval bit in the sypcr to determine whether or not swt ta was needed. if so, execute code to identify bad address. 3. held until another bus cycle starts problem: note: recommend that swt irq be set to the highest level in the system . 1 swt irq and swt ta are active-low signals. 2 swtaval is set to ?1? if swt ta signal is asserted. 9-18 mcf5249um motorola system protection and reset status 1. disable swt by writing a 0 to the swe bit in sypcr. 2. service the swsr, write $55, then write $aa to swsr. this action resets the counter. 3. re-write new swt[1:0] and swp values to sypcr register. 4. re-enable swt by writing a 1 to swe bit in sypcr. users can perform this task in step 3. 9.5.2.1 system protection control register the sypcr controls the software watchdog timer, timeout periods, and software watchdog timer transfer acknowledge. the sypcr is an 8-bit read-write register. the register can be read at any time, but can be written only if swt irq is not pending. at system reset, the software watchdog timer is disabled. table 9-27 system protection control register (sypcr) bits 7 6 5 4 3 2 1 0 field swe1 swri swp swt[1] swt[0] swta swtaval ? reset0000000 r/w r/w r/w r/w r/w r/w r/w r/w addr mbar + $(0x01) table 9-28 system protection control bit descriptions bit name description swe software watchdog enable 0 = swt disabled 1 = swt enabled swri software watchdog reset/interrupt select 0 = if swt timeout occurs, swt generates an interrupt to the core processor at the level programmed into the il bits of icr0. 1 = swt causes soft reset to be asserted for all modules of the part. swp software watchdog prescalar 0 = swt clock not prescaled 1 = swt clock prescaled by a value of 8192 swt[1:0] the software watchdog timing delay bits (along with the swp bit) select the timeout period for the swt as shown in table 9-29 . at system reset, the software watchdog timer is set to the minimum timeout period. table 9-29 swt timeout period swp swt[1:0] swt timeout period 000 2 9 / system frequency 001 2 11 / system frequency system protection and reset status motorola section 9 system integration module 9-19 note: if the swp and swt bits are modified to select a new softwa re timeout, users must peform the software service sequence ($5 5 followed by $aa written to the swsr) before the new timeout period takes effect. 9.5.2.2 software watchdog interrupt vector register the swivr contains the 8-bit interrupt vector the sim returns during an interrupt- acknowledge cycle in response to a swt-generated interrupt. the following register illustrates the swivr programming model. the swivr is an 8-bit supervisor write-only register. this register is set to the uninitialized vector $0f at system reset . 010 2 13 / system frequency 011 2 15 / system frequency 100 2 22 / system frequency 101 2 24 / system frequency 110 2 26 / system frequency 111 2 28 / system frequency table 9-30 swp and swt bit descriptions bit name description swta software watchdog transfer acknowledge enable 0 = swta transfer acknowledge disabled 1 = swta assert transfer acknowledge enabled. after 1 swt timeout period of the unacknowledged assertion of the swt interrupt, the software watchdog transfer acknowledge will assert, which allows swt to terminate a bus cycle and allow the iack to occur swtaval software watchdog transfer acknowledge valid 0 = swta transfer acknowledge has not occurred 1 = swta transfer acknowledge has occurred. write a 1 to clear this flag bit table 9-31 software watchdog interrupt vector register (swivr) bits 7 6 5 4 3 2 1 0 field swiv7 swiv6 swiv5 swiv4 swiv3 swiv2 swiv1 swiv0 reset 0 0 001111 r/w r/w r/w r/w r/w r/w r/w r/w r/w addr mbar + $(0x02) table 9-29 swt timeout period swp swt[1:0] swt timeout period 9-20 mcf5249um motorola cpu stop instruction 9.5.2.3 software watchdog service register the swsr is where the swt servicing sequence should be written. to prevent an swt timeout, users should write a $55 followed by a $aa to this register. both writes must be performed in the order listed prior to the swt timeout, but any number of instructions or accesses to the swsr can be executed between the two writes. if the swt has already timed out, writing to this register will have no effect in negating the swt interrupt. the following register illustrates the swsr programming model. the swsr is an 8-bit write-only register. at system reset, the contents of swsr are uninitialized. 9.6 cpu stop instruction executing the cpu stop instruction does not stop any of the clocks. 9.7 mcf5249 bus arbitration control 9.7.1 default bus master park register the mpark determines the default bus master arbitration between internal transfers. this arbitration is needed because there are two bus masters inside the mcf5249. one is the cpu, the other is the dma unit. both can access internal registers within the mcf5249 peripherals. table 8-7 shows the mpark register bit encoding. the mpark is an 8-bit read-write register. 9.7.1.1 internal arbitration operation the park[1:0] bits are programmed to indicate the priority of internal transfers within mcf5249 resources. the possible masters that can initiate internal transfers internal to the mcf5249 are the core and the on-chip dmas. since the priority between dmas is resolved by their relative priority amongst each other and by programming the bwc bits in their respective dma control registers (see dma section), the mpark bits need only arbitrate priority between the core and the dma module (which contains all four dma channels) for internally generated transfers. table 9-32 software watchdog service register (swsr) bits 7 6 5 4 3 2 1 0 field swsr7 swsr6 swsr5 swsr4 swsr3 swsr2 swsr1 swsr0 reset-------- r/w r/w r/w r/w r/w r/w r/w r/w r/w addr mbar + $(0x03) table 9-33 default bus master register (mpark) bits 7 6 5 4 3 2 1 0 field park[1] park[0] iarbctrl earbctrl showdata - - bcr24bit reset 0 0 0 0 0 0 0 0 r/w r/w r/w r/w r/w r/w r/w addr mbar + $(0x0c) mcf5249 bus arbitration control motorola section 9 system integration module 9-21 there are four arbitration schemes that the mpark[1:0] bits can be programmed to with respect to internally generated transfers. the following summarizes these schemes when earbctrl=0: 1. round robin scheme (park[1:0]=00)-- in this scenario, depending on which master has priority in the current transfer, the other master has priority in the next transfer once the current master finishes. when the processor is initialized, the core has first priority. so for example, if the core is the bus master and is finishing a bus transfer and dma channels 0 and 1 (both set to bwc=010) are asserting an internal bus request signal, then the dma channel 0 would gain ownership of the bus after the core; but after channel_0 finishes its transfer, the core would have ownership of the bus if its request was asserted. note: the internal dma has higher priority than the coldfire core if the internal dma has its bandwidth bwc[2:0] bits set to 000 (maximum bandwidth). 2. park on master core priority (park[1:0]=01) -- any time arbitration is occurring or the bus is idle, the core has priority. the dma module can arbitrate a transfer only when the core?s internal bus request signal is negated. 3. park on master dma priority (park[1:0]=10) -- any time arbitration is occurring or the bus is idle, the dma has priority. the core can arbitrate a transfer only when the dma?s internal bus request signal is negated. 4. park on current master priority (park[1:0]=11)-- whatever the current master is, they have priority. only when the bus is idle can the other master gain ownership and priority of the bus. for example, if out of reset the core has priority it will continue to have priority until the bus becomes idle, and the dma asserts its internal bus request signal. at this point the dma module has priority 9.7.1.2 park register bit configuration the following tables show the encoding for the park[1:0] bit of the mpark register along with the priority schemes for each encoding. table 9-34 default bus master selected with park[1:0] park[1:0] default bus master number 00 round robin between dma and coldfire core 01 park on master coldfire core 10 park on master dma module 11 park on current master table 9-35 round robin (park[1:0] = 00) current highest priority master current lowest priority master next arbitration cycle highest priority master next arbitration cycle lowest priority master core dma dma core dma core core dma 9-22 mcf5249um motorola mcf5249 bus arbitration control table 9-35 shows the round robin configuration of internal module arbitration. depending on which master has current ownership of the bus (i.e. has highest priority), the next arbitration cycle will switch priority to master that had lowest priority on that prior current cycle. park on master core priority (park[1:0] = 01) note: when using the park on current master setting, the first master to arbitrate for the bus becomes the current master. the c orresponding priority scheme should be interpreted as the priority of the next master once the current master finishes. . table 9-36 park on master core priority (park[1:0] = 01) priority bus master name highest coldfire core lowest internal dma priority bus master name highest internal dma lowest coldfire core table 9-37 park on current master priority (park[1:0] = 11) current highest priority master current lowest priority master next arbitration cycle highest priority master next arbitration cycle lowest priority master core dma core dma dma core dma core table 9-38 park bit descriptions bit name description iarbctrl legacy bit. 0 = normal use 1 = do not use earbctrl legacy bit. 0 = normal use 1 = do not use showdata enable this bit to drive internal register data bus to external bus. the earbctrl bit must be set to 1 for this function to work. 0 = do not drive internal register data bus values to external bus 1 = drive internal register data bus values to external bus general purpose i/os motorola section 9 system integration module 9-23 9.8 general purpose i/o s the mcf5249 has a total of 64 general purpose input and output functions defined. two groups of 32-bit registers control these gpios. 9.8.1 general purpose inputs there are 64 defined general purpose input bits. they can be read in registers gpio-read and gpio-read1. these bits reflect the logical value of the pin they are associated with. the gpio-read and gpio-read1 registers always reflect the pin values, independent of the settings in the gpio-function, gpio-en, gpio1-function and gpio1-en registers. it does not matter if the pin is driving data out, or is being driven. the gpio-read and gpio-read1 bit to pin association is detailed in table 9-40 . bcr24bit this bit controls the bcr and address mapping for the dma. the bit allows the byte count register to be used as a 24-bit register. see the dma section for memory maps and bit positions for the bcrs. 0 = dma bcrs function as 16-bit counters. 1 = dma bcrs function as 24-bit counters. table 9-39 gpio registers address name width description reset value access mbar2 + $0x000 gpio-read 32 gpio input value r mbar2 + $0x004 gpio-out 32 gpio output value 0 r/w mbar2 + $0x008 gpio-en 32 output enable 0 r/w mbar2 + $0x00c gpio-function 32 function select 0 r/w mbar2 + $0x0b0 gpio1-read 32 gpio input value r mbar2 + $0x0b4 gpio1-out 32 gpio output value 0 r/w mbar2 + $0x0b8 gpio1-en 32 output enable 0 r/w mbar2 + $0x0bc gpio1-function 32 function select 0 r/w mbar2 + $0x0c0 gpio-int-stat 32 interrupt status r mbar2 + $0x0c0 gpio-int-clear 32 interrupt clear w mbar2 + $0x0c4 gpio-int-en 32 interrupt enable 0 r/w table 9-38 park bit descriptions bit name description 9-24 mcf5249um motorola general purpose i/os note: the cmd_sdio2, sdata0_sdio1, rsto/sdata2_bs2, a25, qspi_cs1, qspi_cs3, sdram_cs2, ebuout2, bufenb2, subr, sfsy, rck, sre, lrck3, swe, and the sclk3 signals are only used in the 160 mapbga package. note: mclk1 and mclk2 will output a clock signal just after reset and before they can be configured as gpio if so desired. the frequency of the clock will be the same as crin prior to initialization of the pll. table 9-40 general purpose input to pin mapping general purpose input read from pin general purpose input read from pin gpio-read(31) cts2_b/adin3/gpi31 gpio1-read(63) gpio-read(30) cts1_b/gpi30 gpio1-read(62) pst3/gpio62 gpio-read(29) qspi_cs0/gpio2 9 gpio1-read(61) pst2/gpio61 gpio-read(28) rxd2/adin2/gpi28 gpio1-read(60) pst1/gpio60 gpio-read(27) rxd1/gpi27 gp io1-read(59) pst0/gpio59 gpio-read(26) qspi_dout/gpio26 gpio1-read(58) cs1/gpio58 gpio-read(25) sdatao1/gpio25 gp io1-read(57) bufenb1/gpio57 gpio-read(24) 1 qspi_cs1/gpio24 1 gpio1-read(56) sdata3/gpio56 gpio-read(23) tin1/gpio23 gpio1-read(55) sda2/gpio55 gpio-read(22) 1 qspi_cs3/gpio22 1 gpio1-read(54) 1 sdata0_sdio1/gpi o54 1 gpio-read(21) qspi_cs2/gpio21 gpio1-read(53) 1 subr/gpio53 1 gpio-read(20) ta/gpio20 gpio1-read(52) sfsy/gpio52 gpio-read(19) ef/gpio19 gpio1-read(51) 1 rck/gpio51 1 gpio-read(18) cflg/gpio18 g pio1-read(50) sclk4/gpio50 gpio-read(17) 1 bufenb2/gpio17 1 gpio1-read(49) 1 sclk3/gpio49 1 gpio-read(16) ide_iordy/gpio1 6 gpio1-read(48) sclk2/gpio48 gpio-read(15) sclk_out/gpio15 gpio1-read(47) gpio-read(14) ide_diow/gpio1 4 gpio1-read(46) lrck4/gpio46 gpio-read(13) cs2/ide_dior/gpio13 gpio1-read(45) 1 lrck3/gpio45 1 gpio-read(12) 1 swe/gpio12 1 gpio1-read(44) lrck2/gpio44 gpio-read(11) 1 cs3/sre/gpio11 1 gpio1-read(43) gpio-read(10) bclk/gpio10 gpio1-read(42) sdatai4/gpi42 gpio-read(9) sdata1_bs1/gpio9 gp io1-read(41) sdatai3/gpi41 gpio-read(8) gpio1-read(40) gpio-read(7) 1 sdram_cs2/gpio7 1 gpio1-read(39) ebuin4/adin1/gpi39 gpio-read(6) gpio6 gpio1-re ad(38) ebuin3/adin0/gpi38 gpio-read(5) gpio5 gpio1-read(37) ebuin2/gpi37 gpio-read(4) ddata3/gpio4 gpio1-read(36) ebuin1/gpi36 gpio-read(3) scl2/gpio3 gpio1-read(35) gpio-read(2) ddata2/gpio2 gpio1-read(34) 1 cmd_sdio2/gpio34 gpio-read(1) ddata1/gpio1 gpio1-read(33) tin0/gpi33 gpio-read(0) ddata0/gpio0 gpio1-read(32) general purpose i/os motorola section 9 system integration module 9-25 note: ebuout1 and ebuout2 will output a clock signal just after reset and before they can be configured as gpio. the frequency of the clock output will be crin/16. all four pins can still be used for gpio. the user needs to ensure that, when one of these four pins is assigned as a gpio control within the system, the use will not cause the application to exhibit problems when the clock is active just after reset and before the boot code sets them to gpio mode, e.g., do not use these pins to switch a critical circuit on/off. 9.8.1.1 general purpose input interrupts eight general purpose inputs, those associated with gpio-read(7:0), have interrupt capability. on every low-to-high edge of these inputs, one of the bits 0-7 of register gpio-int-stat is set. on every high-to-low edge of the inputs, one of the bits 8-15 is set. clear is done by writing a ?1? to the corresponding bit in gpio-int-clear register. if any bit in gpio-int-stat is set, and the corresponding bit in gpio-int-en is set, an interrupt will be made pending on the secondary interrupt controller. the registers gpio-int-stat , gpio-int-clear and gpio-int-en also control some audio interrupts. set the gpio_function register bit to 1 or 0 for interrupts, as applicable. table 9-41 gpio-int-stat, gpio-int-clear and gpio-int-en interrupts event gpio-int-stat, gpio-int-clear, gpio-int-en bit number secondary interrupt controller number gpi0 l-h 0 32 gpi1 l-h 1 33 gpi2 l-h 2 34 gpi3 l-h 3 35 gpi4 l-h 4 36 gpi5 l-h 5 37 gpi6 l-h 6 38 gpi7 l-h 7 39 gpi0 h-l 8 32 gpi1 h-l 9 33 gpi2 h-l 10 34 gpi3 h-l 11 35 gpi4 h-l 12 36 gpi5 h-l 13 37 gpi6 h-l 14 38 gpi7 h-l 15 39 cd-rom decoder newblock 16 56 9-26 mcf5249um motorola general purpose i/os 9.8.2 general purpose outputs there are 64 defined general purpose output bits. they are controlled by registers gpio-out, gpio-en, gpio-function, gpio1-out, gpio1- en and gpio1-function. three bits are needed to control a single general-purpose output. as an example, the logic that drives pin ddata3/gpio34 is shown in figure 9-2 whether the output function of the pin is the primary ddata3 function or general-purpose output 34, is controlled by bit gpio1-function[2]. at power-on, the function is always the primary function. when a ?0? is programmed in any bit of gpio-function or gpio1-funct ion, the corresponding pin gets its primary function. in this case, output drive strength and output value are determined by the primary function logic. when a ?1? is programmed in gpio-funct ion or gpio1-function, the corr esponding pin gets its gpo-function. when a pin is in gpio-mode, drive direction is determined by value in gpio-en or gpio1-en. when a ?0? is programmed in any bit, the corresponding pin is driven to high-impedance state. when a ?1? is programmed, the corresponding pin is driven low or high. when a pin is in gpio-mode, and being driven low-impedance, the actual drive value of the pin is determined by what is programmed in the corresponding bit of registers gpio-out or gpio1-out. if ?0? is programmed here, the pin is driven low. if ?1? is programmed, the pin is driven high. cd-rom decoder ilsync 17 55 cd-rom decoder nosync 18 54 cd-rom decoder crcerror 19 53 cd-rom encoder newblock 20 56 cd-rom encoder ilsync 21 55 cd-rom encoder nosync 22 54 reserved 23 - table 9-41 gpio-int-stat, gpio-int-clear and gpio-int-en interrupts event gpio-int-stat, gpio-int-clear, gpio-int-en bit number secondary interrupt controller number general purpose i/os motorola section 9 system integration module 9-27 figure 9-2 general-purpose pin logic for pin ddata3/gpio34 table 9-42 general-purpose output register bits to pins mapping gpio-function gpio-en gpio-out bit number associated pin pin type gpio1-function gpio1-en gpio1-out bit number associated pin pin type 31 rts2_b/gpo31 o 63 pstclk/gpo63 o 30 rts1_b/gpo30 o 62 pst3/gpio62 i/o 29 qspi_cs0/gpio29 i/o 61 pst2/gpio61 i/o 28 txd2/gpo28 o 60 pst1/gpio60 i/o 27 txd1/gpo27 o 59 pst0/gpio59 i/o 26 qspi_dout/gpio26 i/o 58 cs1/gpio58 i/o 25 sdatao1/gpio25 i/o 5 7 bufenb1/gpio57 i/o 24 qspi_cs1/gpio24 i/o 56 sdata3/gpio56 i/o 23 tin1/gpio23 i/o 55 sda2/gpio55 i/o 22 qspi_cs3/gpio22 i/o 54 sdata0_sdio1/gpi o54 i/o 21 qspi_cs2/gpio21 i/o 53 subr/gpio53 i/o 20 ta/gpio20 i/o 52 sfsy/gpio52 i/o 19 ef/gpio19 i/o 51 rck/gpio51 i/o 18 cflg/gpio18 i/o 50 sclk4/gpio50 i/o 17 bufenb2/gpio17 i/o 49 sclk3/gpio49 i/o 16 ide_iordy/gpio16 i/o 48 sclk2/gpio48 i/o 15 sclk_out/gpio15 i/o 47 14 ide_diow/gpio14 i/o 46 lrck4/gpio46 i/o 13 cs2/ide_dior/gpio13 i/o 45 lrck3/gpio45 i/o 12 swe/gpio12 i/o 44 lrck2/gpio44 i/o gpio1-read[2] ddata3 input value ddata3 drive value gpio1-out[2] ddata drive strength gpio1-en[2] gpio1-function[2] 0 1 0 1 ddata3/gpio34 9-28 mcf5249um motorola general purpose i/os note: the cmd_sdio2, sdata0_sdio1, rsto/sdata2_bs2, a25, qspi_cs1, qspi_cs3, sdram_cs2, ebuout2, bufenb2, subr, sfsy, rck, sre, lrck3, swe, and the sclk3 signals are only used in the 160 mapbga package. note: some pins associated with the general-purpose outputs are output-only. (denoted with ?o? in column ?pin type?). these pins can be tri-stated. if an ?0? is written in the corresponding bit of gpio-en or gpio1-en, the pin is driven to high-impedance state. 11 cs3/sre/gpio11 i/o 43 10 bclk/gpio10 i/o 42 mclk2/gpo42 o 9 sdata1_bs1/gpio9 i/o 41 sdatao2/gpo41 o 8a25/gpo8o 40 7 sdram_cs2/gpio7 i/o 39 mclk1/gpo39 o 6 gpio6 i/o 38 xtrim/gpo38 o 5 gpio5 i/o 37 ebuout2/gpo37 o 4 ddata3/gpio4 i/o 36 ebuout1/gpo36 o 3 scl2/gpio3 i/o 35 tout1/adout/gpo 35 o 2 ddata2/gpio2 i/o 34 cmd_sdio2/gpio3 4 i/o 1 ddata1/gpio1 i/o 33 tout0/gpo33 o 0 ddata0/gpio0 i/o 32 table 9-42 general-purpose output register bits to pins mapping gpio-function gpio-en gpio-out bit number associated pin pin type gpio1-function gpio1-en gpio1-out bit number associated pin pin type motorola section 10 chip-select module 10-1 section 10 chip-select module 10.1 introduction the chip select module provides user-programmable control of the four chip select outputs, two buffer enable outputs and one output-enable signal. this section describes the operation and programming model of the chip-select (cs) registers, including the chip select address, mask, and control registers. 10.1.1 chip select features four programmable chip select signals iordy and ta handshake pins two programmable buffers enable signals for glueless interface to bus buffers address masking for memory block sizes from 64kbytes to 4gbytes programmable wait states port size is 16 bits 10.2 chip-select signals the mcf5249 provides four programmable chip selects that can directly interface with sram, eprom, eeprom, and peripherals. two of these chip selects are usable for at-bus peripherals that need separate read and write strobe, and use iordy signalling to insert wait states. 10.2.1 chip selects 10.2.1.1 cs 0 cs0 is the first chip select and it addresses the boot memory. (a rom or flash memory device.) at power-on reset, all bus cycles are mapped to the cs0. this allows the boot memory to be defined at any address space. cs0 is the only chip select initialized at reset. 10.2.1.2 cs 1/gpio1 cs1 is the second chip select and it can be programmed for an address location as well as for masking, port size and burst capability indication, wait state generation, and internal/external termination. a reset clears all chip select programming 10.2.1.3 cs2/ide-dior /gpio13 and ide-diow /gpio14 these two signals go active during cs2 cycles. ide-dior can be programmed to go active on read and write cycles, or ide-dior can be programmed to go active only on read cycles, and ide-diow only on write cycles. it has identical features as the normal cs 2. it can be programmed for an address location as well as for masking, port size and burst capability indication, wait state generation, and internal/external termination. 10-2 mcf5249um motorola mcf5249chip-select operation ide-dior and ide-diow can also be used as enables to access an ide drive or another at-bus peripheral. this added functionality allows users to insert more than 16 wait states on ide-dior , ide-diow , and allows dynamic cycle termination using the iordy signal. 10.2.1.4 cs3/sre /gpio11 and swe /gpio12 these two signals go active during cs 3 cycles. sre can be programmed to go active on read and write cycles, or sre can be programmed to go active only on read cycles, and swe only on write cycles. it has identical features as the normal cs3. it can be programmed for an address location as well as for masking, port size and burst capability indication, wait state generation, and internal/external termination. note: the swe and sre signals are only used on the 160 mapbga package. sre and swe can also be used as enables to access an ide drive or another at-bus peripheral. this added functionality allows users to insert more than 16 wait states on sre , swe , and allows dynamic cycle termination using the iordy signal. 10.2.2 output enable oe /gpio9 the oe /gpio9 signal interfaces memory and/or peripherals to enable a read transfer. it is asserted and negated on the falling edge of the clock. this signal is asserted only when there is a match of one of the chip selects for the current address decode. 10.2.3 buffer enable signals - bufenb1 and bufenb2 the bufenb1/gpio57 and bufenb2/gpio17 signals are intended to enable bus buffers sitting between some chip select modules and the mcf5249 bus. bufenb1 is always active on cs 0, bufenb2 is always inactive on cs 0. it is programmable if the bus buffer signals go active on cs 1, cs 2, and cs 3. note: the bufenb2 signal is only used in the 160 mapbga package. 10.2.4 iordy - bus termination signal the iordy signal controls the insertion of wait states on the third and fourth chip select. 10.3 mcf5249chip-select operation 10.3.1 chip-select module the chip select module provides a glueless interface to many types of external memory. the module contains the necessary external control signals to interface to sram, prom, eprom, eeprom, flash and peripherals. some features of the chip selects are controlled by the ideconfig1 and ideconfig2 registers. these are described in section 10.4 . each of the four chip select outputs has an associated mask register and control register. mcf5249chip-select operation motorola section 10 chip-select module 10-3 chip selects (cs 0, cs 1/gpio1, dior /diow (cs2), sre /swe (cs3)): each has a 16-bit base address register. each has a 32-bit mask register, which provides 16-bit address masking and access control. each has a 16-bit control register, which provides port size and burst capability indication, wait state generation, and automatic acknowledge generation features. note: the swe and sre signals are only used on the 160 mapbga package. chip select 0 provides special functionality. it is a ?global? chip select after reset and provides relocatable boot rom capability. in addition to the 2 external chip select outputs, the module contains 2 chip selects (cs2 and cs3) for use with at-bus peripherals such as ide drives and flash card interfaces. capabilities for cs2 and cs3 are like cs1, but there are some enhancements for typical at-bus features. the enhancements are described in section 10.4 . 10.3.1.1 general chip select operation the general-purpose chip selects are controlled by the chip select mask register (csmr), the chip select control register (cscr), and by the chip select address register (csar). there is one csar, csmr, and cscr for each of the chip selects (cs0 ?cs3 ). chip selects (cs [3:0]): the chip select address register controls the base address space of the chip select. the chip select mask register controls the memory block size and addressing attributes of the chip select. the chip select control register programs the features of the chip select signals. the mcf5249 processor compares the address and mask in cs [3:0] control registers. if the address and attributes do not match in a single chip select register, the cycle will terminate in error. table 10-1 shows the type of access depending on what matches are made in the cs control registers. table 10-1 accesses by matches in cs control registers number of chip selects register matches type of access none error 1 single as defined by chip select control register multiple external 2,3 note 1: the cycle will not terminate, and the bus will hang. watchdog timer may recover from hung bus. note 2: external termination by pulling the ta pin low is required. glueless interface with memory is not possible. if ta pin is not pulled low, cycle will not terminate causing the bus to hang. note 3: for the case of multiple chip selects matching, all of the matching chip selects will be asserted. 10-4 mcf5249um motorola programming model 10.3.1.1.1 port sizing the mcf5249 only supports a 16-wide port size (ps). the size of the port controlled by a chip-select is programmable. the port size is specified by the (ps) bits in the chip select control register (cscr). it should always be programmed as a 16-wide port. see section 10.4.2.3 for details. 10.3.2 global chip-select operation cs0 is the global (boot) chip select and it allows address decoding for the boot rom before system initialization occurs. its operation differs from the other external chip-select outputs following a system reset. after system reset, cs0 is asserted for every external access. internal accesses can be made to go external by setting the internal bus arbitration control (iarbctrl) bit of the default bus master (mpark) register in the system integration module (sim). no other chip-select can be used while cs0 is a global chip select. cs0 operates in this manner until the valid bit is set in chip select mask register csmr0[0], at which point cs1 may be used. at reset, the port size and automatic acknowledge functions of the global chip-select are determined. the reset value is always auto-acknowledge (aa) with 15 wait states, and the port size bits (ps[1:0]) in cscr0 are set to ?10?, 16 bit port. provided the required address range is first loaded into chip select address register (csar), cs0 can be programmed to continue to decode for a range of addresses after the valid (v) bit is set. after the v-bit is set for cs0 , global chip-select can be restored only with another system reset. 10.4 programming model 10.4.1 chip-select registers memory map table 10-2 shows the memory map of all the chip-select registers. reading reserved locations returns zeros. similarly, the cscrs should be accessed through a mov.l to longword address offset they belong to, while reading and writing to the lower 16-bits of the longword data transfer (data[15:0]). note: all of these accesses are longword in length, instead of word length, even though both the csars and cscrs use only 16 bits in the 32-bits registers. programming model motorola section 10 chip-select module 10-5 table 10-2 memory map of chip-select registers address name width description reset value 2 access 3 mbar + 0x80 csar 0 16 chip-select address register?bank 0 uninitialized r/w mbar + 0x84 csmr 0 32 chip-select mask register?bank 0 uninitialized (except v = 0) r/w mbar + 0x88 cscr 0 16 chip-select control register?bank 0 bem = 1; bstr = bstw = 0; aa = 1; ps1 = 1; ps0 = 0; ws3 = ws2 = ws1 = ws0 = 1 r/w mbar + 0x8c csar 1 16 chip-select address register?bank 1 uninitialized r/w mbar + 0x90 csmr 1 32 chip-select mask register?bank 1 uninitialized (except v = 0) r/w mbar + 0x94 cscr 1 16 chip-select control register?bank 1 uninitialized r/w mbar + 0x98 csar 2 16 chip-select address register?ide uninitialized r/w mbar + 0x9c csmr 2 32 chip-select mask register?ide uninitialized (except v = 0) r/w mbar + 0xa2 cscr 2 16 chip-select control register?ide uninitialized r/w mbar + 0xa4 csar 3 16 chip-select address register?fc uninitialized r/w mbar + 0xa8 csmr 3 32 chip-select mask register?fc uninitialized (except v = 0) r/w mbar + 0xae cscr 3 16 chip-select control register?fc uninitialized r/w note 1: addresses not assigned to a register and undefined register bits are reserved for future expansion. write accesses to these reserved address spaces and reserved register bits are undefined. note 2: the reset value column indicates the register initial value at reset. certain registers may be uninitialized upon reset, (they could contain random values.) note 3: the access column indicates whether the corresponding register allows both read/write functionality (r/w), read-only functionality (r), or write-only functionality (w). a read access to a write-only register will return zeros. a write access to a read-only register will have no effect. 10-6 mcf5249um motorola programming model 10.4.2 chip select module registers the various chip select registers in the module are described as follows. 10.4.2.1 chip select address register csar0 and csar1 determine the base address of the corresponding chip select pin, and are read/writable. csar2 and csar3 determine the base address of the ide and flash card interfaces. these read/write registers are 32-bit in length. the value stored in each csar register corresponds to a[31:16]. these registers are uninitialized by reset. shows the bit assignment for the base address. 10.4.2.2 chip select mask register the chip select mask registers csmr0 to csmr3 are readable and writable. they determine the address mask for cs 0, cs 1, dior/diow, sre/swe, respectively. in addition, csmr[3:0] determines which type of access is allowed for these signals. each csmr is a 32-bit read/write control register that physically resides in the chip select module. with the exception of bit 0 (v-bit), which is initialized to 0 on reset, all other bits in csmr[3:0] are uninitialized by reset. the csmr is illustrated in the following table. note: the swe and sre signals are only used on the 160 mapbga package. table 10-3 chip select address register (csar) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field ba3 1 ba3 0 ba2 9 ba2 8 ba2 7 ba2 6 ba2 5 ba2 4 ba2 3 ba2 2 ba2 1 ba2 0 ba1 9 ba1 8 ba1 7 ba1 6 reset ???????????????? r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w bits 1514131211109876543210 field ???????????????? reset ???????????????? r/w mbar (0x80), mbar (0x8c), mbar (0x98), mbar (0xa4), table 10-4 chip select bit descriptions bit name description ba[31:16] the base address field defines the base address location of memory dedicated to chip select cs [3:0]. these bits are compared to bits 31?16 on the internal core address bus to determine if the chip select memory is being accessed. programming model motorola section 10 chip-select module 10-7 table 10-5 chip select mask register (csmr) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field bam 31 bam 30 bam 29 bam 28 bam 27 bam 26 bam 25 bam 24 bam 23 bam 22 bam 21 bam 20 bam 19 bam 18 bam 17 bam 16 reset ???????????????? r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w bits 1514131211109876543210 field ???????wp?amc/iscsducudv reset ??????????????? 0 r/w mbar (0 x 84), mbar (0 x 90), mbar (0 x 9c), mbar (0 x a8), table 10-6 chip select mask bit descriptions bit name description bam [31:16] the base address mask field defines the chip select block size through the use of address mask bits. any set bit masks the corresponding base address register (csar) bit (the base address bit becomes a don?t care in the decode). 0 = corresponding address bit is used in chip select decode 1 = corresponding address bit is a don?t care in chip select decode the block size for cs [3:0] is equal to 2 n , where n = (number of bits set in the base address mask field of the respective csmr) + 16. for example, if csar0 were set at $0000 and csmr0 were set at $0008, then chip select cs0 would address two discontinuous memory blocks of 64 kbytes each: the first block would be from $00000000 to $0000ffff and the second block would be from $00080000 to $0008ffff. stated another way, if any of the upper 16-bits in the csmr0 were set, then the corresponding address bit is a don?t care in the chip select decode. another example might be if cs0 were to access 32 mbytes of address space starting at location $0 and cs1 has to begin at the next byte after cs0 for an address space of 16mb. then: csar0 = $0000, (upper 16 bits of) csmr0 = $01ff, and csar1 = $0200, (upper 16 bits of) csmr1 = $00ff. address space mask bits 10-8 mcf5249um motorola programming model 10.4.2.3 chip select control register cscr0 to cscr3 control the auto acknowledge, external master support, port size, burst capability, and activation of each of the chip selects. for cscr0, bits bstr, and bstw are initialized to 0 by reset; bits ws[3:0] and bem are initialized to 1 by reset; while aa, ps1, and ps0 are loaded with ?110?, respectively at reset. for cscr1 to cscr3 none of the bits are initialized at reset. these are shown in tables table 10-7 and table 10-8 . wp, am, c/i, sc, sd, uc, ud these fields mask specific address spaces, placing the chip select in a specific address space or spaces. if an address space mask bit were cleared, an access to a location in that address space can activate the corresponding chip select. if an address space mask bit were set, an access to a location in that address space becomes a regular external bus access, and no chip select is activated. am: alternate master access (dma) c/i: interrupt cycle access sc: supervisor code access sd: supervisor data access uc: user code access ud: user data access for each address space mask bit (am, c/i, sc, sd, uc, ud): 0 = do not mask this address space for the chip select. an access using the chip select can occur for this address space. 1 = mask this address space from the chip select activation. if this address space is accessed, no chip select activation occurs on the external cycle. wp the write protect bit can restrict write accesses to the address range in a csar. an attempt to write to the range of addresses specified in a csar that has this bit set results in the appropriate chip select not being selected. no exception occurs. 0 = both read and write accesses are allowed. 1 = only read access is allowed. am the alternate master bit indicates if alternate master (dma) access is allowed or denied 0 = alternate master access is allowed 1 = alternate master access is denied v the valid bit indicates that the contents of its address register, mask register, and control register are valid. the programmed chip selects do not assert until the v-bit is set (except for cs0 which acts as the global (boot) chip select?see section . a reset clears the v-bit in each csmr. 0 = chip select invalid 1 = chip select valid table 10-7 chip select control register 0 bits 15141312111098765 4 3 210 table 10-6 chip select mask bit descriptions bit name description programming model motorola section 10 chip-select module 10-9 cs0 is the global (boot) chip select which allows address decoding for boot rom before system initialization occurs. its operation differs from the other external chip select outputs following a system reset. field ? ? ws3 ws2 ws1 ws0 ? aa ps1 ps0 ? bstr bstw ? ? ? reset ??1111?110? 0 0 ??0 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w mbar (0 x 8a) table 10-8 chip select control register 1 to 3 bits 15141312111098765 4 3 210 field ? ? ws3 ws2 ws1 ws0 ? aa ps1 ps0 bstr bstw ? ? ? reset ??????????? ? ? ??0 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w mbar (0 x 96), mbar (0 x a2), mbar (0 x ae) table 10-9 chip select bit descriptions bit name description ws[3:0] the wait states field defines the number of wait states that are inserted before an internal transfer acknowledge is generated. if the aa bit is cleared, ta must be asserted by the external system regardless of the number of wait states generated. bstr the burst read enable field specifies whether burst reads are used for the memory associated with each chip select. 0 = breaks data larger than the specified port size into individual non-burst reads that equals the specified port size. for example, a longword read from an 16-bit port would be broken into two individual wordreads. 1 = enables burst read of data larger than the specified port size. bstw the burst write enable field specifies whether burst writes are used for the memory associated with each chip select. 0 = break data larger than the specified port size into individual non-burst writes that equals the specified port size. for example, a longword write to an 16-bit port would be broken into two individual word writes. 1 = enables burst write of data larger than the specified port size. aa the auto-acknowledge enable field determines the assertion of the internal transfer-acknowledge for accesses specified by the chip select address. 0 = no internal transfer acknowledge (ta ) is asserted. 1 = internal acknowledge (ta) is asserted as specified by ws[3:0]. table 10-7 chip select control register 0 10-10 mcf5249um motorola programming model 10.4.2.4 code example the following code provides an example of how to initialize the chip- selects. csar0 equ mbarx+$080;chip select 0 address register csmr0 equ mbarx+$084;chip select 0 mask register cscr0 equ mbarx+$088;chip select 0 control register csar1 equ mbarx+$08c;chip select 1 address register csmr1 equ mbarx+$090;chip select 1 mask register cscr1 equ mbarx+$094;chip select 1 control register ; all other chip selects should be programmed and made valid before global ; chip select is de-activated by validating cs0 ; program chip select 1 registers move.l#$00000000,d0;csar1 base addresses $00000000 (to $001fffff) move.ld0,csar1;and $80000000 (to $801fffff) move.l#$000009b0,d0;cscr1 = 2 wait states, aa=1, ps=16-bit, bem=1, move.ld0,cscr1;bstr=1, bstw=0 move.l#801f0001,d0;address range from $00000000 to $001fffff and move.ld0,csmr1;$80000000 to $801fffff ;wp,em,c/i,sc,sd,uc,ud=0, v=1 ;program chip select 0 registers move.l#$00800000,d0;csar0 base address $00800000 (to $009fffff) move.ld0,csar0 move.l#$00000d80,d0;cscr0 = 3 wait states, aa=1, ps=16-bit, bem=0, move.ld0,cscr0;bstr=0, bstw=0 ; program chip select 0 mask register (validate chip selects) move.l#001f0001,d0;address range from $00800000 to $009fffff move.ld0,csmr0;wp,em,c /i,sc,sd,uc,ud=0; v=1 ps[1:0] the port size field specifies the width of the data associated with each chip select. it determines where data is driven during write cycles and where data is sampled during read cycles. port size should always be programmed to 16 bits for mcf5249. 00 = reserved 01 = 8-bit port size 10 = 16-bit port size?data sampled and driven on d[31:16] only 11 = 16-bit port size?data sampled and driven on d[31:16] only note: a0 is not available on the external bus. table 10-9 chip select bit descriptions bit name description motorola section 11 timer module 11-1 section 11 timer module 11.1 timer module overview this section describes the configuration and operation of the two general purpose timer modules (timer0 and timer1). the timer module incorporates two independent, general purpose 16-bit timers, timer0 and timer1. the output of an 8-bit prescaler clocks each 16-bit timer. the prescaler input can be the system clock, the system clock divided by 16, or the timer input (tin) pin. figure 11-1 is a block diagram of the timer module. the two timer input pins and two timer output pins are multiplexed with gpio pins. upon reset, they are all programmed as timer pins. note: the maximum system clock is 1/2 the cpu clock. 11.2 timer features each of the general purpose 16-bit timers provide the following features: maximum period of 3.8 seconds at 70 mhz. 14.28 ns minimum resolution at 70 mhz system clock programmable sources for the clock input, including external clock input-capture capability with programmable trigger edge on input pin output-compare with programmable mode for the output pin free run and restart modes maskable interrupts on input capture or reference-compare 11.3 timer signals this section describes the signals utilized in the timer module. 11.3.1 timer inputs the timer input pins tin0/ gpi33 and tin1/ gpio23 are multiplexed with general purpose inputs. at reset, the function is timer input. 11.3.2 timer outputs the timer output pins tout0/ gpo33 and tout1/ gpo35 are multiplexed with general purpose outputs. at reset, the function is timer output. 11-2 mcf5249um motorola general-purpose timer units figure 11-1 timer block diagram module operation 11.4 general-purpose timer units the general-purpose timer units provide the following features: users can program timers to count and compare to a reference value stored in a register or capture the timer value at an edge detected on the tin pin an 8-bit prescalar output clocks the timers users can program the prescalar clock input programmed events generate interrupts users can configure the tout pin to toggle or pulse on an event the minimum resolution of each timer is one system clock cycle (14.28 ns at 70 mhz). the maximum timeout period (16*256*65536)/70mhz = 3.83 seconds. ($0 - $ffff = 65536 decimal.) timer clock generator divider mode register prescalermode bits timer counter 15 0 reference register 15 0 capture register 15 0 15 0 70 event reg capture detection system clock or system clock/16 tin tout data bus (16) general-purpose timer clock irq bus general-purpose timer registers motorola section 11 timer module 11-3 11.4.1 selecting the prescaler users can select the prescalar clock from the main clock (divided by 1 or by 16) or from the corresponding timer input tin pin. tin is synchronized to the internal clock. the synchronization delay is between two and three main clocks. tin must meet the setup time spec shown in table 21-9 on page 9 . the clk bits of the corresponding timer mode register (tmr) select the clock input source. the prescaler is programmed to divide the clock input by values from 1 to 256. the prescalar output is used as an input to the 16-bit counter. 11.4.2 capture mode the timer has a 16-bit timer capture register (tcr) that latches the counter value when the corresponding input capture-edge detector senses a defined transition of tin. the capture edge (ce) bits in the tmr select the type of transition triggering the capture. a capture event sets the cap bit in the timer event register (ter) and issues a maskable interrupt. 11.4.3 configuring the ti mer for refe rence compare users can configure the timer to count until it reaches a reference value at which time it either starts a new time count immediately or continues to run. the free run/restart (frr) bit of the tmr selects either mode. when the timer reaches the reference value, the ref bit in the ter register is set and issues an interrupt if the output reference interrupt (ori) enable bit in tmr is set. 11.4.4 configuring the timer for output mode the timer can send an output signal on the timer output (tout) pin when it reaches the reference value as selected by the output mode (om) bit in the tmr. this signal can be an active-low pulse or a toggle of the current output under program control. 11.5 general-purpose timer registers users can modify the timer registers at any time. table 11-1 shows the timer programming model. table 11-1 programming model for timers timer 0 address timer 1 address timer module registers mbar+$140 mbar+$180 timer mode register (tmrn) mbar+$144 mbar+$184 timer reference register (trrn) mbar+$148 mbar+$188 timer capture register (tcrn) mbar+$14c mbar+$18c timer counter (tcnn) mbar+$151 mbar+$191 reserved timer event register (tern) 11-4 mcf5249um motorola general-purpose timer registers 11.5.1 timer mode regis ters (tmr0, tmr1) the tmr is a 16-bit memory-mapped register. this register programs the various timer modes and is cleared by reset. table 11-2 timer mode register (tmrn) bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field prescaler value (ps7 - ps0) ce1 - ce0 om ori frr clk1 - clk0 reset reset 0 0 0 0 0 0 0 0 0000 0 00 0 r/w read/write supervisor or user mode addr mbar+$140, mbar+$180 table 11-3 timer mode bit descriptions bit name description ps7?ps0 the prescaler value is programmed to divide the clock input by values from 1 to 256. the value 00000000 divides the clock by 1; the value 11111111 divides the clock by 256. prescalar value = $[ps7 - ps0] + 1 ce1?ce0 capture edge and enable interrupt 11 = capture on any edge and enable interrupt on capture event 10 = capture on falling edge only and enable interrupt on capture event 01 = capture on rising edge only and enable interrupt on capture event 00 = disable interrupt on capture event om output mode 1 = toggle output 0 = active-low pulse for one system clock cycle (14.28 ns at 70 mhz) ori output reference interrupt enable 1 = enable interrupt upon reaching the reference value 0 = disable interrupt for reference reached (does not affect interrupt on capture function) note: if ori is set when the ref event is asserted in the timer event register (ter), an immediate interrupt occurs. if ori is cleared while an interrupt is asserted, the interrupt negates. frr free run/restart 1 = restart: timer count is reset immediately after reaching the reference value 0 = free run: timer count continues to increment after reaching the reference value general-purpose timer registers motorola section 11 timer module 11-5 11.5.2 timer reference registers (trr0, trr1) the trr is a 16-bit register that contains the reference value that is compared with its respective, free-running timer counter (tcn), as part of the output-compare function. trr is a memory-mapped read/write register. trr is set at reset. the reference value is not matched until tcn equals trr, and the prescaler indicates that the tcn should be incremented again. thus, the reference register is matched after (trr+1) time intervals. 11.5.3 timer capture registers (tcr0, tcr1) the tcr is a 16-bit register that latches the value of the timer counter (tcn) during a capture operation when an edge occurs on the tin pin, as programmed in the tmr. tcr appears as a memory-mapped read-only register and is cleared at reset. clk1?clk0 input clock source for the timer 11 = tin pin (falling edge) 10 = master system clock divided by 16. note: the clock source is synchronized with the timer. however, the divider is not reset to 0 when the timer is stopped, thus successive time-outs may vary slightly in length. 01 = master system clock 00 = stops counter. after the counter is stopped, the value in the timer counter (tcn) register remains constant. rst the reset timer bit performs a software timer reset identical to that of an external reset. all timer registers take on their corresponding reset values. while this bit is zero, the other register values can still be written, if necessary. a transition of this bit from one to zero is what resets the register values. the counter/timer/prescaler is not clocked unless the timer is enabled. 1 = enable timer 0 = reset timer (software reset) table 11-4 timer reference register (trrn) bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field 16-bit reference compare value ref15 - ref0 reset 1 1 1 1 1 1 1 1 1111111 1 r/w read/write supervisor or user mode addr mbar+$144, mbar+$184 table 11-3 timer mode bit descriptions bit name description 11-6 mcf5249um motorola general-purpose timer registers 11.5.4 timer counters (tcn0, tcn1) tcn is a memory-mapped 16-bit up counter that users can read at any time. a read cycle to tcn yields the current timer value and does not affect the counting operation. a write of any value to tcn causes it to reset to all zeros. 11.5.5 timer event registers (ter0, ter1) the ter is an 8-bit register that reports events the timer recognizes. when the timer recognizes an event, it sets the appropriate bit in the ter, regardless of the corresponding interrupt-enable bits (ori and ce) in the tmr. ter appears as a memory-mapped register and can be read at any time. writing a one to a bit will clear it (writing a zero does not affect the bit value); more than one bit can be cleared at a time. the ref and cap bits must be cleared before the timer will negate the irq to the interrupt controller. reset clears this register. table 11-5 timer capture register (tcr) bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field 16-bit capture counter value cap15 - cap0 reset 0 0 0 0 0 0 0 0 0000000 0 r/w read only supervisor or user mode addr mbar+$148, mbar+$188 table 11-6 timer counter (tcn) bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field 16-bit timer counter value count15 - count0 reset 0 0 0 0 0 0 0 0 0000000 0 r/w read/write supervisor or user mode addr mbar+$14c, mbar+$18c table 11-7 timer event register (tern) bits 7 6 5 4 3 2 1 0 field reserved read as 0 ref cap reset 0 0 0 0 0 0 0 0 r/w read/write supervisor or user mode addr mbar+$151, mbar+$191 general-purpose timer registers motorola section 11 timer module 11-7 11.5.6 timer initialization example code there are two timers on the mcf5249. with a 70mhz clock, the maximum period is 3.8 seconds and a resolution of 14.28 ns. the timers can be free running or count to a value and reset. the following examples set up the timers: timer 0 will count to $afaf, toggle its output, and reset back to $0000. this will continue infinitely until the timer is disabled or a reset occurs. no interrupts are set. prescale is set at 256 and the system clock is divided by 16, therefore resolution is (16*(256))/70 mhz = 58.51us. timeout period is (16*256*44976)/70mhz = 2.63s ($0 - $afaf = 44976 decimal). timer 1 will be free-running and send out a logic pulse every time it compares the count value in the trr register. value, which for now, is randomly chosen as $1234. prescale is set at 127 with the sys_clock initially divided by 16 (by setting bits 2&1 of the tmr register to 10 therefore, resolution is (16*(127))/70mhz = 29us. interrupts are not enabled. note: the timers were initialized in the sim to have interrupt values. the following examples have the interrupts disabled. the initialization in the sim configuration was for reference. the timers cannot provide interrupt vectors, only autovectors. autovectors and icrs have been set up as follows. the interrupt levels and priorities were chosen by random for demonstrative purposes. users should define the interrupt level and priorities for their specific application. 11.5.6.1 timer 0 (timer mode register) bits 15:8 sets the prescale to 256 ($ff) bits 7:6 set for no interrupt (?00?) bits 5:4 sets output mode for ?toggle?. no interrupts(?10?) bits 3 set for ?restart? (?1?) bits 2:1 set the clocking source to system clock/16 (?10?) bit 0 enables/disables the timer (?0?) move.w #$ff2c,d0;setup the timer mode register (tmr1) table 11-8 timer event bit descriptions bit name description bits 7?2 reserved for future use. these bits are currently 0 when read. cap if a one is read from the capture event bit, the counter value has been latched into the tcr. the ce bit in the tmr enables the interrupt request caused by this event. writing a one to this bit will clear the event condition. ref if a one is read from the output reference event bit, the counter has reached the trr value. the ori bit in the tmr enables the interrupt request caused by this event. writing a one to this bit will clear the event condition. 11-8 mcf5249um motorola general-purpose timer registers move.w d0,tmr1;; bit 1 is set to 0 to disable the timer move.w #$0000,d0; writing to the timer counter with any value resets it to zero move.w d0,tcn1; 11.5.6.2 timer 0 (timer reference register 0) the trr register is set to $afaf. the timer will count up to this value (tcn = trr), toggle the ?tout? pin, and reset the tcn to $0000. move.w #$afaf,d0;setup the timer reference register (trr1) move.w d0,trr1 other registers used for timer 0 tcr1;timer1 capture register, 16-bit, r ter1;timer1 event register, 8-bit, r/w 11.5.6.3 timer 1 (timer mode register 1) bits 15:8 set the prescale to 127 ($7f) bits 7:6 set the capture mode and interrupt (?00?) bits 5:4 set the output mode for ?pulse? and no interrupt (?00?) bits 3 set for free-running (?0?) bits 2:1 set the clocking source to clk/16 (?10?) bit 1 enables the timer (?0?) move.w #$7f04,d0;setup the timer mode register (tmr2) move.w d0,tmr2; move.w #$1234,d0;set the timer reference to $1234 move.w d0,trr2; move.w #$0000,d0;writing to the timer counter with move.w d0,tcn2; any value resets it to zero 0ther registers used: tcr2;timer1 capture register, 16-bit, r ter2;timer1 event register, 8-bit, r/w motorola section 12 analog to digital converter (adc) 12-1 section 12 analog to digital converter (adc) 12.1 adc overview the adc functionality is based on the sigma-delta concept using 12-bit resolution. the adc uses four muxed inputs with the following pin names. 1. ebuin3_adin0_gpi38 2. ebuin4_adin1_gpi39 3. rxd2_adin2_gpi28 4. cts2_adin3_gpi31 the digital portion of the adc is internal while the analog voltage comparator must be provided from an external source. the single output on the tout1_adout_gpo35 pin provides the reference voltage in pwm format therefore this output requires an external integrator circuit (resistor/capacitor) to convert it to a dc level to be used by the external comparator circuit. a circuit example is shown below. only one input can be converted at any one time. the input to be converted is selected via the source select bits (8 + 9) of the adconfig register. a software interrupt can be provided when the adc measurement cycle is complete. interrupt can be disabled. note: adc functionality is shared with ebuin3 and ebuin4, uart1 (rxd and cts), and tout1. 12-2 mcf5249um motorola adc functionality 12.2 adc functionality figure 12-1 adc with on-chip and external parts the adc uses the sigma-delta modulation principle. the adc external components are external comparators. see figure 12-1 , vdd/2-1 for channel 1. one input of the comparator connects to vdd/2, the other input connects to a capacitor that integrates the charge. the integrated charge is proportional to the voltage on input in0 , and on the average duty cycle on device pin adout . as shown in figure 12-1 , the mcf5249 selects one of the four inputs using the mux. the adout value is calculated using the flip-flop and the buffer. the feed-back loop keeps the voltage on the capacitor close to vdd/2. in this way, the voltage on input in0 is proportional to the duty cycle of the signal on adout . the circuit measures the duty cycle of the adout signal. every time adout is high, the counter increments. at the 4096th ad_clk clock pulse value, the counter is latched into the register and adinterrupt is generated. the counter is then reset. on reception of adinterrupt , the mcf5249 reads advalue(11:0) from advalue register. the value should be in the range 0-4096, which indicates the duty cycle of adout. table 12-1 adc registers address mbar2bas + name widt h description reset value acces s 0x402 adconfig 16 ad configuration rw 0x406 advalue 16 ad measurement result r vdd/2 in0 r adin0 vdd/2 in1 r adin1 vdd/2 in2 r adin2 vdd/2 in3 r adin3 4 r 4 x comparator or op-amp adout mux d q ad_clk +1 r loadpulse e adinterrupt advalue(15:0) 1 2 3 4 5 6 7 8 9 adc functionality motorola section 12 analog to digital converter (adc) 12-3 note: 1. measurement frequency and interrupt frequency is adclk / 4096 note: 2. for the circuit shown figure 12-1 , the adout_drive should be set to 00. other circuits can use settings 10 or 11. note: 3. ad resolution is 12 bits. ad precision depends on many factors, and is tbd. note: 4. only one channel can be measured simultaneously. table 12-2 adconfig (adconfig) register bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field----- adout_se l source select int intclear interrup t enable adout_drive adclk_sel reset----- 0 000 - - - - - --- r/w r/w address mbar2bas + 0x402 table 12-3 adconfig register bit descriptions field field name description reset 10 adout_sel 1: tout1/gpo35/adout pin function is adout 0: tout1/gpo35/adout pin function is not adout 0 9:8 source select 00: in0 01: in1 10: in2 11: in3 000 7int intclear (on read): ?1? indicates interrupt pending ?0? no interrupt pending (on write): ?1? clear interrupt ?0? no action 6 interrupt enable 0: interrupt disabled 1: interrupt enabled 5:4 adout_dri ve 01: adout tri-state 00: adout drives +vdd for hi, gnd for lo 11: adout drives +vdd for hi, hi-z for lo 10: adout drives hi-z for hi, gnd for lo 3:0 adclk_sel 0: adclk = busclk 1: adclk = busclk / 2 2: adclk = busclk / 4 3: adclk = busclk / 8 4: adclk = busclk / 16 5: adclk = busclk / 32 6: adclk = busclk / 64 7: adclk = busclk / 128 8: adclk = busclk / 256 12-4 mcf5249um motorola adc functionality table 12-4 advalue register bits1514131211109876543210 field - - - - advalue reset - - - - - - - - - - - - - - - - r/w r address mbar2bas + 0x406 table 12-5 advalue register bit descriptions field field name description reset 11:0 advalue ad measurement result motorola section 13 ide and flashmedia interface 13-1 section 13 ide and flashmedia interface 13.1 ide and smartmedia overview the mcf5249 device system bus allows connection of an ide hard disk drive and smartmedia flash card with a minimum of external hardware. the following block diagram shows the bus set-up for the mcf5249 device. the diagram includes an interface with an ide device and a smartmedia device. note: smartmedia refers to flash memory cards such as compact flash. for other flashmedia such as secure digital (sd), multimedia card (mmc) or memory stick, refer to section 13.4 . figure 13-1 bus setup with ide and smartmedia interface there are two sets of buffers in this set-up. the sdram is connected directly to the coldfire bus. the ?first? bus buffer isolates the sdram bus from the flash rom device. after the bus buffer, the flash bufen1_b a24-a1 d16-d31 en dir ?244 16-bit tranceiver rw_b smartmedia flash cle ale io1-8 we re ce rb wp sre swe gpo gpi from reset circuit da0 da1 da2 cs0- cs1- dd(15:0) dior- diow- iordy intrq reset ide-dior ide-diow ide-iordy gpi gpo ide interface ?244 en dir 16-bit tranceiver bufen2_b oe_b sdram control signals sdram flash rom cs0 gpo gpi gpo bufenb1 bufenb2 13-2 mcf5249um motorola memory is connected. the ide and smartmedia interfaces share most signals with the coldfire address and data bus. the ?second? bus buffer prevents the flash rom signals from going to/from ide and smartmedia interfaces. to support this bus set-up, a number of signals are available. bufenb1 : active-low external buffer enable. this enable is always active when cs0 is active, and should enable a buffer going to the boot rom. bufenb2 : active-low external buffer enable. this enable is always inactive when cs0 is active, and should enable a buffer for peripheral devices, except boot rom. ide-dior, ide-diow : active-low ide bus read and write strobe. ide-iordy : active-high ?ready? indication from ide device to mcf5249. sre, swe: active-low smartmedia read and write strobe note: the swe and sre signals are only used on the 160 mapbga package. the extra bus signals, and their configuration are detailed in the following section. 13.1.1 buffer enables bufenb1, bufenb2 , and associated logic. buffer enables bufenb1 and bufenb2 allow a seamless interface to external bus buffers. the buffers may be placed on the address and the data bus. figure 13-2 buffer enables (bufenb1 and bufenb2) bufenb1 is always active on cs0. bufenb2 is never active on cs0. either of the buffer enables can be programmed to be active on cs1, cs2, or cs3. as shown in figure 13-2 , the buffer enables bufenb1 and bufenb2 will go active at time cspre before the falling edge of the chip select signal, and continue to be active for a time cspost after the rising edge of the chip select signal. the pre-drive time cspre is realized by delaying the falling edge of the select signal. if pre-drive time cspre is programmed non-zero, and internal coldfire cycle termination is used, chip select length will be cspre shorter than the programmed length. times cspre, cspost are the same for both bufenb1 and bufenb2 . times cspre, cspost are independently programmable for every select. buffer enable configuration is programmable using the ide_config1 register. bufenbx cspre cspost csx_core bufenx_b cspre cs0, cs1, dior, diow, sre, swe cspost motorola section 13 ide and flashmedia interface 13-3 table 13-1 ideconfig1 register address mbar2bas + access size bits name description mbar2bas+0x18c rw 32 ide config1 configuration of buffer enable generation table 13-2 ideconfig1 bits ide config1 bits field name meaning res 2:0 cs0pre pre-drive for cs0 000: no predrive 001: 1 clock 010: 2 clocks 011: 3 clocks 100: 4 clocks 101: 5 clocks 0 4:3 cs0post post-drive for cs0 00: no post-drive 01: 1 clock post-drive 10: 2 clock post drive 11: 3 clock post drive 0 7:5 cs1pre pre-drive for cs1 000: no predrive 001: 1 clock 010: 2 clocks 011: 3 clocks 100: 4 clocks 101: 5 clocks 0 9:8 cs1post post-drive for cs1 00: no post-drive 01: 1 clock post-drive 10: 2 clock post drive 11: 3 clock post drive 0 12:10 cs2pre pre-drive for dior, diow 000: no predrive 001: 1 clock 010: 2 clocks 011: 3 clocks 100: 4 clocks 101: 5 clocks 0 14:13 cs2post post-drive for cs2 00: no post-drive 01: 1 clock post-drive 10: 2 clock post drive 11: 3 clock post drive 0 16 bufen1cs1 en 0: bufen1 inactive on cs1 cycles 1: bufen1 active on cs1 cycles 0 13-4 mcf5249um motorola note: the swe and sre signals are only used on the 160 mapbga package. 13.1.2 generation of ide-di or, ide-diow, sre, swe these four signals are generated internally by gating the cs2_pin and cs3_pin signals with rwb. dior and diow are created by gating cs2_pin with rwb. sre and swe are created by gating cs3_pin with rwb. note: the swe and sre signals are only used on the 160 mapbga package. dior and sre are programmable if these signals go active on write cycles. if these signals are programmed to go active during write cycles, they can be used as extra chip enables. (cs2 and cs3). 17 bufen1cs2 en 0: bufen1 inactive on dior, diow cycles 1: bufen1 active on dior, diow cycles 0 18 bufen1cs3 en 0: bufen1 inactive on sre, swe cycles 1: bufen1 active on sre, swe cycles 0 19 bufen2cs1 en 0: bufen2 inactive on cs1 cycles 1: bufen2 active on cs1 cycles 0 20 bufen2cs2 en 0: bufen2 inactive on dior, diow cycles 1: bufen2 active on dior, diow cycles 0 21 bufen2cs3 en 0: bufen2 inactive on sre, swe cycles 1: bufen2 active on sre, swe cycles 0 24:22 cs3pre pre-drive for sre, swe 000: no predrive 001: 1 clock 010: 2 clocks 011: 3 clocks 100: 4 clocks 101: 5 clocks 0 26:25 cs3post post-drive for cs1 00: no post-drive 01: 1 clock post-drive 10: 2 clock post drive 11: 3 clock post drive 0 27 dior on write 0: dior not active during write cycles 1: dior active during write cycles 0 28 sre active during write 0: sre not active during write 1: sre active during write 0 table 13-2 ideconfig1 bits ide config1 bits field name meaning res motorola section 13 ide and flashmedia interface 13-5 figure 13-3 dior and sre timing diagram 13.1.3 cycle termination on cs 2, cs3 (dior, diow, sre, swe) dedicated logic has been added to the mcf5249 to allow ide compliant cycles on the bus. the logic can generate the transfer acknowledge (ta) signal for cs2 and cs3 accesses. the manner in which the ta signal is generated is programmable using the ide config 2 register, and is compatible with ide/smartmedia requirements. note: the swe and sre signals are only used on the 160 mapbga package. table 13-3 ideconfig register address mbar2bas + access size bits name description mbar2bas +0x190 rw 32 ide config2 configuration of ta generation on cs2, cs3 table 13-4 ideconfig bit description ide config2 bits field name meaning res 7:0 waitcount3 cs3 delay count. controls ta timing for cs3 0 15:8 waitcount2 cs2 delay count. controls ta timing for cs2 0 16 ta enable 3 1: generate ta for cs3 accesses 0: do not generate ta for cs3 0 17 iordy enable 3 1: allow iordy to delay ta generation for cs3 0: do not look at iordy for cs3 ta generation 0 18 ta enable 2 1: generate ta for cs2 accesses 0: do not generate ta for cs2 0 19 iordy enable 2 1: allow iordy to delay ta generation for cs2 0: do not look at iordy for cs2 ta generation 0 cs2 pin cs3 pin rwb dior (writes disabled) diow sre (writes disabled) swe dior (writes enabled) sre (writes enabled) dior dior diow sre sre swe 13-6 mcf5249um motorola smartmedia interface setup the logic is identical for cs2 (dior, diow), and for cs3 (sre, swe). the timing diagram for a non-iordy controlled ide/smartmedia ta generation is shown in figure 13-4 . figure 13-4 non-iordy controlled ide/smartmedia ta timing the system also supports dynamic lengthening of cs2 (dior, diow) and cs3 (sre, swe) cycles using the iordy signal. the timing diagram is shown in figure 13-5 . figure 13-5 cs2 (dior, diow) and cs3 (sre, swe) cycle timing note: t2 is relevant for iordy controlled cycles only. note: the swe and sre signals are only used on the 160 mapbga package. 13.2 smartmedia interface setup the smartmedia block must be connected to the bus as follows: re input connect to mcf5249 sre output we input connect to mcf5249 swe output d0-7 connect to mcf5249 data bus wires 31-24 ce connect to always low ale connect to general purpose output cle connect to general purpose output r/b connect to general purpose input table 13-5 dior, diow, and iordy timing parameters timing parameter description min typ max t1 dior, diow low to ta sre, swe low to ta (waitcount2 + 2.5)t (waitcount3 + 2.5)t t2 dior, diow low to iordy low sre, swe low to iordy low 0 0 (waitcount2 + 1.5)t (waitcount3 + 1.5)t t3 iordy high to ta 2t 3t csx_pin ta_b t1 csx_pin ta_b t2 iordy t3 smartmedia interface setup motorola section 13 ide and flashmedia interface 13-7 to set up the smartmedia interface perform the following tasks. 1. program the three chip select registers inside the chip select modules (csar3, csmr3, cscr3) as follows: ? csar3, csmr3 must be programmed to see the ide interface in the correct part of the coldfire address map. ? cscr3 bit fields must be programmed as follows: aa: 0 (ta signal generated by ideconfig2 register logic) ws[3:0]: not relevant ps[1:0]: 01 (8 bit port size) bstr, bstw: 00 (no burst read/write cycles) 2. program the ide config1 register. only fields cs2pre, cs2post, bufen1cs2en, bufen2cs2en, and sre active during write are relevant. the values required for the buffer enable signals bufen1cs2en and bufen2cs2en depend on the hardware configuration. if two buffers are used in cascade, both bits must be 1. fields cs2pre and cs2post are relevant and are detailed later in this section. 3. program the ide config2 register as follows: ? ta enable 3 = ?1? ? iordy enable 3 = ?0?. ? waitcount3 is required and is explained later in this section. note: the swe and sre signals are only used on the 160 mapbga package. 13.2.1 smartmedia timing figure 13-6 smartmedia timing table 13-6 smartmedia timing values smartmedi a timing symbol typical value ns controlled by setting equation (approximately) comment tcls, tclh, tals, talh 20, 40 - cs2pre > t1 - tbuf realized in software because cle and ale are driven by gpio. trea 45 waitcount3 (waitcount3 + 3.5)t > trea tdh 20 cs3post cs3post > tdh to meet this timing, typical value for cs3post is 20 ns clk bufenb swe write data t11 t12 t13 address bufenb 13-8 mcf5249um motorola setting up the ide interface under typical circumstances, cs3pre = 0 clocks, waitcount3 = 1 or 2. note: if cs3post is set to 2, every write cycle is lengthened with 1 clock. if cs3post is set to 3, every write cycle is lengthened with 2 clocks. 13.3 setting up the ide interface to set up the ide interface, complete the following tasks. 1. program the chip select 2 registers inside the chip select modules. (csar2, csmr2, cscr2). ? csar2, csmr2 must be programmed to see the ide interface in the correct part of the coldfire address map. ? cscr2 bit fields must be programmed as follows: aa: 0 (ta signal generated by ideconfig2 register logic) ws[3:0]: not relevant ps[1:0]: 10 (16 bit port size) bstr, bstw: 00 (no burst read/write cycles) 2. program the ide config1 register. fields cs2pre, cs2post, bufen1cs2en, bufen2cs2en, and sre active during write are relevant. the values required for the buffer enable signals bufen1cs2en and bufen2cs2en depend on the hardware configuration. if two buffers are used in cascade, both bits must be 1. fields cs2pre and cs2post are relevant and are explained later in this section. 3. program ideconfig2 register. program this register as follows: ? ta enable 2 = ?1? ? iordy enable 2 = ?1? if iordy is connected from the ide drive to the mcf5249 chip. ? iordy enable 2 = ?0? if iordy wait handshake is not used. ? waitcount2 is required and is explained later in this section. 13.3.1 ide timing diagram figure 13-7 ide timing bclk address bufenb1, bufenb2 dior, diow iordy ta read data write data t1 tbuf cs2pre t5 t2 t9 tr ta data in time (waitcount2 + 3.5)t t5a bufenb2 bufenb1 setting up the ide interface motorola section 13 ide and flashmedia interface 13-9 under typical circumstances, cs2pre = 4 clocks, t2 = 7 clocks, dead time between 2 accesses = 4 clocks. in this case, the cycle time is 150 ns, yielding a 12 mbyte/sec. sustained rate. note: if cs2post is set to 2, every write cycle is lengthened with 1 clock. if cs2post is set to 3, every write cycle is lengthened with 2 clocks. this marginally reduces throughput. note: a 3-clock cycle hold time to any mcf5249 external access has been added. as a result, hold time address to ta and write data to ta is not an issue. table 13-7 ide timing values ata timing symbol ata4 value controlled by setting equation (approximately) comment t1 25 cs2pre cs2pre > t1 - tbuf tbuf is external buffer enable time. cs2pre must be set high enough to provide sufficient address-to-dior, diow setup time. typical cs2pre values will range from 3 to 5 sclk clocks. t2 70 waitcount2 (waitcount2+ 4)t > t2 t2 is the dior, diow low period. to meet 70 ns t2 period, waitcount2 must be set to 3. t5a 50 waitcount2 (waitcount2 + 3.5)t > t5a + tio + tbuf tio: input/output delay of device. typ. 10 ns tbuf: external buffer delay. typ. 15 ns to meet this timing, waitcount2 must be set to 4-5 ta 35 waitcount2 (waitcount2 + 1.5)t > ta + tio to meet this timing, waitcount2 must be set 3-4. tr 0 - 3t > tbuf + tdel - tr tdel: time difference between path from iordy and from read data read data in device must be valid 3 clocks after iordy going high. t9 10 cs2post cs2post > t9 to meet this timing, typical value for cs2post is 10 ns. 13-10 mcf5249um motorola flashmedia interface 13.4 flashmedia interface the mcf5249 is capable of interfacing with sony memorystick and secure digital flash cards. the interface can handle one of them at any given time, but not both at the same time. figure 13-8 flashmedia block diagram in the flashmedia interface there are four blocks: 1. the clock generator generates the clock to the flash device 2. the processor interface handles interrupts and processor i/o. 3. interface shift register 1 4. interface shift register 2 each interface shift register is a serial interface to the flashmedia device. the two interfaces share the clock generating circuitry. the flash media interface can operate in two modes. 1. memorystick mode. in this mode it is possible to connect two sony memorystick cards. each interface can handle one memorystick card. the two interfaces share only the clock generating logic, all other logic is fully independent. 2. securedigital mode. in this mode it is possible to connect one sd card. the sd card has a command line and 1 or 4 serial data lines. the interface shift register 1 will handle communication on the serial data lines, the interface shift register 2 will handle communication on the command line. from a software point of view, the two interfaces operate independently. 13.4.1 flashmedia interface registers the flashmedia interface contains eight 32-bit registers clock generator interface shift register 1 interface shift register 2 processor interface sclk_out_pin bs1_pin sdata3_pin sdata2_pin sdata1_pin sdata0_sdio1_pin bs2_pin cmd_sdio2_pin stopclock1 stopclock2 sclk_out_pin bs1_pin sdata3_pin sdata2_pin sdata1_pin sdata0_sclio1 _ bs2_pin cmd_sclio2_pi n flashmedia interface motorola section 13 ide and flashmedia interface 13-11 . 13.4.1.1 flashmedia clock generation and configuration clock generation and selection of the card type is accomplished by programming the flashmediaconfig register as shown in the following table. note: 1. the clock generator will increase the length of some sc lk_out clock cycles to avoid bus contention when the sdio pin switches from input to output, or from output to input mode. the clock generator will stop the sclk_out clock if this is necessary to avoid buffer overrun or buffer underrun. note: 2. it is legal to reprogram these bits while t he interface is running. no glitch will occur on sclk_out. note: 3. in sd mode, this bit should be programmed 1. in memorystick mode, programming 1 gives more relaxed timing, however memorystick specs stipulate it should be 0. table 13-8 flashmedia registers address mbar2bas + access size bits name description 0x460 rw 32 flashmediaconfig clock and general configuration 0x464 rw 32 flashmediacmd1 command register for interface 1 0x468 rw 32 flashmediacmd2 command register for interface 2 0x46c rw 32 flashmediadata1 data register for interface 1 0x470 rw 32 flashmediadata2 data register for interface 2 0x474 rw 32 flashmediastatus status register 0x478 rw 32 flashmediainten interrupt enable register 0x47c r 32 flashmediaintstat interrupt status register 0x47c w 32 flashmediaintclear interrupt clear register table 13-9 flashmediaconfig register configuration flashmediac onfig bits field name meaning res notes 7:0 clockcount0 (clockcount0+1) is the sclk_out_pin low period in number of bus clocks 15 1,2 15:8 clockcount1 (clockcount1+1) is the sclk_out_pin high period in number of bus clocks 15 1,2 17,16 stopclock 00: normal operation 01: freeze clock low 10: freeze clock high 01 2 18 - reserved 0 19 receiveedge 1: receive data on falling edge of sclk_out pin 0: receive data on rising edge of sclk_out pin 03 21:20 cardtype 00: sony memorystick 01: securedigital, 1-bit serial data 11: securedigital, 4-bit serial data 0 13-12 mcf5249um motorola flashmedia interface 13.4.2 flashmedia interface operation the flashmedia interface is build around two interface shift registers , each of which work independently. the following figure shows a block diagram of one interface shift register. figure 13-9 one interface shift register the processor interface sends commands to the interface shift register. one command instructs the interface shift register to do one of the following: transmit a packet of n bits to the flashmedia device. the number of bits n is programmable. it is also programmable if bits 15:0, or bits 47:0 in sd wide bus mode, need to be replaced with a valid crc or not. crc insertion is possible for memorystick data packet and securedigital data packets. crc insertion is not possible for securedigital command packets. receive a packet of n bits from the flashmedia device. the number of bits n is programmable. after reception of all bits, the interface shift register will display on status line crc_is_0 if crc check was successful or not. crc check is done for memorystick data packets and for securedigital data packets. no crc check is available for sd command packets. wait for an interrupt event from the flashmedia device after writing a command to the interface shift register, the processor needs to monitor txbufferempty or rxbufferfull, and read or write data to the interface as required. when the transmit shift register is empty, new data is loaded from the txbufferreg. if the transmit buffer register is empty, the interface shift register will stop the sclk_out clock, and wait for new data to be written in the txbufferreg. when the receive shift register is full, data is transferred to the rxbufferreg. if the receive buffer register is full, the interface shift register will stop the sclk_out clock, and wait until the rxbufferreg is read to empty. if the number of bits in the packet to sent/receive from the flashmedia is greater than 32, multiple longword transfers to the buffer register are needed. all of these, except the first, contain 32 packet bits. the last data word for the transfer always contains packet bits 31-0, even if crc transmit or check is on. if e.g. a 48-bit transfer is requested to the flashmedia, the first data word will contain 16 bits, the second one will contain 32 bits. the first word is lsb aligned for receive data, msb aligned for transmit data. interface shift register bs (memorystick mode only) serial data commandbits bitcounter shift_busy int_level crc_is_0 txbufferempty rcvbufferfull loadtxshiftreg storercvshiftreg stopclock (to clock generator) serial data rxbufferfull flashmedia interface motorola section 13 ide and flashmedia interface 13-13 this is also true if crc insertion is involved. if a 4096 bit packet + 16 bit crc need to be transmitted to the flashmedia, 129 long-word transfers are needed. the first long-word will contain packet bits 4095:4080, msb aligned. the last longword will contain packet bits 15:0 padded with 16 zeros or ones. the padded value will be replaced with the crc by the transmit interface. (if the interface is programmed to do so.) during and after transmission of a command, the processor can monitor the interface shift register status by looking at some status signals. shift_busy this signal is high while the data transmission is in progress. int_level during interrupt commands, a high on this signal indicates an interrupt event coming from the flashmedia. crc_is_0 after a read transmission is completed, this signal indicates if the packet crc was 0 or not. bitcounter. this counter indicates the number of bits still to be exchange with the flashmedia card. 13.4.2.1 flashmedia command registers in memorystick mode 13.4.2.2 flashmedia command register 1 in secure digital mode table 13-10 flashmedia command registers (memorystick mode) flashmediacmd1 flashmediacmd2 bits field name rw meaning res notes 15:0 bitcounter rw write to this field the number of bits to be exchanged with the flash card. read value is the number of bits remaining. 0 19:16 cmdcode 0001: read data (memorystick) 0010: write data (memorystick) 1000: wait for int (memorystick) 0 20 next bs next value to output on bs pin (memorystick) 0 21 sendcrc 0: no crc inserted 1: packet bits 0-15 will be replaced with crc 0 table 13-11 flashmedia command register 1 (secure digital mode) flashmediacmd1 bits field name rw meaning res notes 15:0 bitcounter rw write to this field the number of bits to be exchanged with the flash card. read value is the number of bits remaining. 0 19:16 cmdcode 0 20 next bs next value to output on bs pin (memorystick) 0 13-14 mcf5249um motorola flashmedia interface 13.4.2.3 flashmedia command register 2 in secure digital mode the commands and their meanings are described in detail later in this section. 21 sendcrc 0: no crc inserted 1: packet bits 0-15 will be replaced with crc 0 22 wideshift 0: 1-bit data bus 1: 4-bit data bus 0 note: the following codes are relevant for flashmedia command register 1: flashmediacmd1[22:16] = 0x44: wait for read, 4 bit wide flashmediacmd1[22:16] = 0x04: wait for read, 1 bit wide flashmediacmd1[22:16] = 0x66: write data, 4 bit wide flashmediacmd1[22:16] = 0x26: write data, 1 bit wide flashmediacmd1[22:16] = 0x00: receive handshake flashmediacmd1[22:16] = 0x08: wait for busy signalling table 13-12 flashmedia command register 2 (secure digital mode) flashmediacmd2 bits field name rw meaning res notes 15:0 bitcount er rw write to this field the number of bits to be exchanged with the flash card. read value is the number of bits remaining. 0 19:16 cmdcode 0 20 next bs next value to output on bs pin (memorystick) 0 21 sendcrc reserved, should be 0 0 22 drivecmd 0: do not drive command line 1: start driving command line after receiving card status response 0 23 drivedat a 0: do not drive data line 1: start driving data line after command transmission end. note: the following codes are relevant for flashmedia command register 2: flashmediacmd2[23:16] = 0x46: send read data command to sd. (drive cmd line after receiving flash status, do not drive data lines) flashmediacmd2[23:16] = 0x40: receive status for read data command from sd flashmediacmd2[23:16] = 0xc6: send write data command to sd. (drive cmd line after receiving flash status. drive data line after sending command.) flashmediacmd2[23:16] = 0xc0: receive status for write data command from sd flashmediacmd2[23:16] = 0x06: send non-data command to sd flashmediacmd2[23:16] = 0x00: receive status fo r non-data command, stop driving cmd and data lines. table 13-11 flashmedia command register 1 (secure digital mode) flashmediacmd1 bits field name rw meaning res notes flashmedia interface motorola section 13 ide and flashmedia interface 13-15 13.4.3 flashmedia data register 13.4.3.1 flashmedia status register 13.4.4 flashmedia interrupt interface there are 12 interrupt sources associated with the flashmedia interface. register flashmediaintstat allows the viewing of pending interrupts. register flashmediainten allows the enabling of interrupts (?1? = enabled, ?0? = disabled). some interrupts can be cleared by writing a ?1? to the corresponding bit of the flashmediaintclear register . table 13-13 flashmedia data registers flashmediadata1 flashmediadata2 bits field name rw meaning res notes 31:0 txbufferreg w data written to this register will be transmitted 0 31:0 rcvbufferreg r read receive data from this register 0 table 13-14 flashmedia status register flashmediastat bits field name rw meaning res notes 0 crc_is_0_1 r interface 1 crc status. valid after read phase end. ?1? indicates crc ok, ?0? indicates crc fail 0 1 shift_busy1 r interface 1 shift status. ?1? indicates interface busy shifting data, ?0? indicates interface idle 0 2 int_level1 r interface 1 interrupt indicator. ?1? indicates interrupt condition, requiring attention, ?0? indicates no interrupt 0 3 crc_is_0_2 r interface 2 crc status. valid after read phase end. ?1? indicates crc ok, ?0? indicates crc fail 0 4 shift_busy2 r interface 2 shift status. ?1? indicates interface busy shifting data, ?0? indicates interface idle 5 int_level2 r interface 2 interrupt indicator. ?1? indicates interrupt condition, requiring attention, ?0? indicates no interrupt 13-16 mcf5249um motorola flashmedia interface 13.4.5 flashmedia interface o peration in memorystick mode before any data exchange is possible with the memorystick, the flashmediaconfig register must be written to set up the clock and the card type. after this, the card is accessed by issuing one of three possible command sequences. each new command sent to the card, must toggle the bs line going out. the ?handshake? phase of the memorystick can be implemented as a 16-bit read. there is no specific handshake command. note: the flashmedia interface can handle two memorystick cards. one is attached to the primary interface, the other to the secondary interface. there is one potential issue. if there is a buffer full or a buffer empty on one interface, the system will freeze the outgoing sclk signal, which causes the second interface to go into a wait-state as well. table 13-15 flashmedia interrupts flashmediaintstat flashmediainten flashmediaintclear bits int name meaning reset interrupt associated interrupt 0 shiftbusy1fall interrupt set on falling edge of shift_busy_1 intclear 60 1 shiftbusy1rise interrupt set on rising edge of shift_busy_1 intclear 60 2 intlevel1fall interrupt set on falling edge of int_level_1 intclear 60 3 intlevel1rise interrupt set on rising edge of int_level_1 intclear 60 4 shiftbusy2fall interrupt set on falling edge of shift_busy_2 intclear 59 5 shiftbusy2rise interrupt set on rising edge of shift_busy_2 intclear 59 6 intlevel2fall interrupt set on falling edge of int_level_2 intclear 59 7 intlevel2rise interrupt set on rising edge of int_level_2 intclear 59 8 rcv1full interrupt set if receive buffer reg 1 full read data 58 9 tx1empty interrupt set if transmit buffer reg 1 empty write data 58 10 rcv2full interrupt set if receive buffer reg 2 full read data 57 11 tx2empty interrupt set if transmit buffer reg 2 empty write data 57 flashmedia interface motorola section 13 ide and flashmedia interface 13-17 13.4.5.1 reading data from the memorystick figure 13-10 reading data from memorystick figure 13-11 reading data from memorystick timing in the timing diagram, the assumption is made that the processor reads the full receive buffer register before the next 32 bits are received. if this is not the case, the flashmedia interface will stop the outgoing sclk clock which prevents data overrun. write cmd_reg(19:16) = 0001 write cmd_reg(15:0) : no. of bits to read from stick write cmd_reg(20): new value on bs pin write cmd_reg(21): 0 cmd_reg(15:0) = 0 ? or fall. edge on shiftbusy ? read bit crc_is_0 in status reg end yes rcv_data_reg full ? no read rcv_data_reg yes no rcv_data_reg full ? read rcv_data_reg yes no write to cmd register bitcounter 48 0 bs_pin sdio_out shift_busy sdio_in 47 33 32 31 10 47 46 45 33 32 31 10 30 rcv_data_reg_full memory stick interface timing diagram for cmd_reg(19:16) = 0001 (read data from stick) sclk_out sclk_out write to cmd register bitcounter bs_pin sdio_out sdio_in shift_busy rcv_data_reg_full 13-18 mcf5249um motorola flashmedia interface 13.4.5.2 writing data to the memorystick figure 13-12 writing data to memorystick a timing diagram is also given. in this timing diagram, the assumption is made the processor writes the empty transmit buffer register before the next 32 bits are transmitted. if this is not the case, the flashmedia interface will stop the outgoing sclk clock, and in this way prevent data underrun. figure 13-13 writing data to memorystick timing write cmd_reg(19:16) = 0010 write cmd_reg(15:0) : no. of bits to write to stick write cmd_reg(20): new value on bs pin write cmd_reg(21): 0 : no crc will be inserted write cmd_reg(21): 1 : crc will be inserted cmd_reg(15:0) = 0 ? or fall. edge on shiftbusy ? end yes tx_data_reg empty? no write tx_data_reg yes no write to cmd register bitcounter 48 0 bs_pin sdio_out shift_busy sdio_in 33 32 31 10 sclk_out 47 46 45 47 46 45 33 32 31 10 sclk_out write to cmd register bitcounter bs_pin sdio_out sdio_in shift_busy flashmedia interface motorola section 13 ide and flashmedia interface 13-19 13.4.5.3 interrupt from memorystick figure 13-14 interrupt from memorystick figure 13-15 interrupt from memorystick write cmd_reg(19:0) = 80000h write cmd_reg(20): new value on bs pin write cmd_reg(21): 0 end program flow diagram for int transfer to memorystic k wait for 5 sclk clock periods turn off sclk clock (turning clock off is option) int_level = 1 ? or rising edge on int_level ? no yes int found write to cmd register bitcounter bs_pin sdio_out shift_busy sdio_in int_level memory stick interface timing diagram for cmd_reg(19:16) = 1000 (wait for int from stick) sclk_out 0 sclk_out write to cmd register bitcounter bs_pin sdio_out sdio_in shift_busy int_level 13-20 mcf5249um motorola flashmedia interface 13.4.6 flashmedia interface operatio n in secure digital (sd) mode all interactions to the secure digital (sd) card can be broken down in a number of cascaded elementary operations. there are three elementary operations to the card in sd mode: sent command to card read data from card (one or more packets) write data to card (one or more packets) 13.4.6.1 sent command to card figure 13-16 sent command to card the sent-command sequence first sends out a command on the cmd line, then receives a card response on the same cmd line. after receiving the card response, the host may drive the cmd and data lines depending on the values of the drivecmdmask and drivedatamask. note: both lines must be driven if the next operation is sending a write data packet to the card. the cmd line must be driven, while data lines are kept z when the next operation is receiving read data from the card. both cmd and data lines are kept z when no data follows the command. while the host is sending data and receiving status from the card, it must look for events on the shiftbusy2 status bit in the flashmediastatus register. it is also possible to capture these events using the shiftbusy2rise and shiftbusy2fall interrupts. to exchange data with the card, the host must write the flashmediadata2 register when tx2empty interrupt is set, or read flashmediadata2 when rcv2full is set. this can be done by using interrupts, by polling flashmediaintstat, or by using a dma channel on flashmediadata2. a number of bits/bytes/longwords corresponding with cmdbitcount must be written to flashmediadata2 during the command transmission. all words, except the first word, contain 32 bits of data. the first word contains the remainder. the data in the first word is left-justified. no crc logic is present in hardware, so crc must be inserted by software. zz write flashmediacmd2 = 0x60000 + cmdbitcount + drivecmdmask + drivedatamask write one or more times to flashmediadata2 zz se host command cmdbitcount se card response rspbitcount pp p card driving bus p z p z p z p z z z p z p z p z p z z note 1 note 2 write flashmediacmd2 = rspbitcount + drivecmdmask + drivedatamask read one or more times from flashmediadata2 write flashmediacmd2 = 0 note 1: if drivecmdmask = 0x40000, cmd line is driven p after receiving card response if drivecmdmask = 0, cmd line is not driven (z) after receiving card response note 2: if drivedatamask = 0x80000, data lines are driven p after receiving cmd response. if drivedatamask = 0, data lines are not driven (z) after receiving cmd response. note 3:to stop host driving p on cmd or data lines, write flashmediacmd2 with drivedatamask or drivecmdmask 0 cmd line data lines shift_busy2 bitcounter2 note 4: host interface will stop sclk_out clock when needed to prevent transmit underrun or receive overrun. (not shown) flashmedia interface motorola section 13 ide and flashmedia interface 13-21 a number of bits/bytes/longwords corresponding with respbitcount must be read from flashmediadata2 during the response phase. all words, except the first word, contain 32 bits of data. the first word contains the remainder. the data in the first word is right-justified. no crc logic is present in hardware, so crc must be inserted by software. the writing of rspbitcount + drivecmdmask + drivedatamask to flashmediacmd2 must take place after shiftbusy2 has gone high. 13.4.6.2 write data to card following two timing diagrams show write data to card sequence with and without busy response from the card. figure 13-17 write data to card with busy write flashmediacmd1 = 0x40000 + wideshiftmask write one or more times to flashmediadata1 pp se databitcount pp p host driving bus write flashmediacmd1 = 0x260000 + databitcount + wideshiftmask data lines shift_busy1 note 3: host interface will stop sclk_out clock when needed to prevent transmit underrun or receive overrun. (not shown) data crc bitcounter1 note 1: for 4-bit wide bus, wideshiftmask is 0x400000, crc length is 64 bits for 1-bit wide bus, wideshiftmask = 0, crc length is 16 bits. note 2: if read data packet followed by another read data packet (block read), set readdatamask = 0x40000. if only one read data packet, set readdatamask = 0. z z s crc status z z p e card driving bus write flashmediacmd1 = 0x000003 + read flashmedia- data1 (get crc status) host driving bus 13-22 mcf5249um motorola flashmedia interface figure 13-18 write data to card without busy the write data sequence sends out a write packet on the data line, receives a crc status response from the card, and then looks for a potential busy. the databitcount is the number of bits in the packet. this includes the crc bits. there are 16 crc bits for the 1-bit bus, 64 crc bits for the 4-bit bus. the number of bits/bytes/longwords that need to be written to flashmediadata1 corresponds with databitcount. the user needs to write dummy data in stead of the crc bits to flashmediadata1. (use all-zero or whatever. the crc value is calculated inside the flashmediainterface, and the crc bits written to flashmediadata1 are discarded. all words, except the first word, written to flashmediadata1 contain 32 bits of data. the first word contains the remainder. data in the first word must be left-justified. to read the crc status, the host must read flashmediadata1 once. the crc status are the three lsb?s of the value read. during this sequence, the host must look for events on shift_busy1 and interrupt1. this is accomplished by polling flashmediastatus or flashmediaintstatus, or by waiting for interrupts shiftbusy1rise, shiftbusy1fall, interrupt1rise, interrupt1fall. to read/write data to/from flashmediadata1, the host can poll flashmediaintstat, wait for interrupt, or use a dma channel. in the following figures, the data lines default to a ?p? state: strong ?1? driven by host. this is only the case if drivedatamask was set during last write to flashmediacmd2. writing 0x000003 to flashmediacmd1 must take place after shiftbusy1 has gone high. one or more write packets can be sent to the card using this timing diagram. write flashmediacmd1 = 0x40000 + wideshiftmask write one or more times to flashmediadata1 pp se databitcount pp p host driving bus write flashmediacmd1 = 0x260000 + databitcount + wideshiftmask data lines shift_busy1 note 3: host interface will stop sclk_out clock when needed to prevent transmit underrun or receive overrun. (not shown) data crc bitcounter1 note 1: for 4-bit wide bus, wideshiftmask is 0x400000, crc length is 64 bits for 1-bit wide bus, wideshiftmask = 0, crc length is 16 bits. note 2: if read data packet followed by another read data packet (block read), set readdatamask = 0x40000. if only one read data packet, set readdatamask = 0. z z s crc status e card driving bus write flashmediacmd1 = 0x000003 + read flashmedia- data1 (get crc status) host driving bus s interrupt1 write flashmediacmd1= 0x80000 check interrupt1 in flashmediastatus write flashmediacmd1= 0 l .. l e z p z card signals busy flashmedia interface motorola section 13 ide and flashmedia interface 13-23 figure 13-19 read data from card the read sequence reads a packet on the data line. the databitcount is the number of bits in the packet. this includes the crc bits. there are 16 crc bits for the 1-bit bus, 64 crc bits for the 4-bit bus. the number of bits/bytes/longwords that need to be read from flashmediadata1 corresponds with databitcount. the crc will be read from flashmediadata1 too. the user need not check the crc in software. this is done in hardware. the result can be retrieved in bit crcstatus1 in register flashmediastatus after packet read end. all words, except the first word, read from flashmediadata1 contain 32 bits of data. the first word contains the remainder. data in the first word is right-justified. during this sequence, the host must look for events on shift_busy1 and interrupt1. this can be done by polling flashmediastatus or flashmediaintstatus, or by waiting for interrupts shiftbusy1rise, shiftbusy1fall, interrupt1rise, interrupt1fall. to read/write data to/from flashmediadata1, the host can poll flashmediaintstat, wait for interrupt, or use a dma channel. the writing of databitcount + readdatamask + wideshiftmask to flashmediacmd1 must take place after shiftbusy1 has gone high. one or more read packets can be received from the card using this timing diagram 13.4.7 commonly used commands in sd mode some pseudo-code descriptions are given in this section for sent command, read multiple block, and write multiple block commands. 13.4.7.1 send command to card (no data) this sequence is intended for commands that require status response from the card, but no data transfer between host and card. there are no provision to do crc insertion or check for command and response packets. all need to be done in software. /* write command to host */ cmdbitcount = 46 flashmediacmd2 = 0x060000 + cmdbitcount while(cmdbitcount > 0) write flashmediacmd1 = 0x40000 + wideshiftmask read one or more times from flashmediadata1 zz se databitcount pp p card driving bus write flashmediacmd1 = databitcount + readdatamask + wideshiftmask data lines shift_busy1 note 3: host interface will stop sclk_out clock when needed to prevent transmit underrun or receive overrun. (not shown) data crc c ounter1 note 1: for 4-bit wide bus, wideshiftmask is 0x400000, crc length is 64 bits for 1-bit wide bus, wideshiftmask = 0, crc length is 16 bits. note 2: if read data packet followed by another read data packet (block read), set readdatamask = 0x40000. if only one read data packet, set readdatamask = 0. read flashmediastatus extract bit crcok1 13-24 mcf5249um motorola flashmedia interface { if(flashmediadata2 empty) { write data to flashmediadata2 cmdbitcount:= cmdbitcount - 32; } } /* one of the two waits need to be done. */ /* first one is more suitable for polling */ /* second one more suitable for interrupt driven */ wait until ((flashmediacmd2 & 0xffff) == 0) or wait until (shiftbusy2fall event) /* receive status from host */ wait until (shiftbusy2rise event) or wait until ((flashmediastatus & 8)!= 0) respbitcount = 46 or 134 /* depends on command */ flashmediacmd2 = respbitcount; while(respbitcount > 0) { if(flashmediadata2 full) { read data from flashmediadata2 respbitcount:= respbitcount - 32; } } } 13.4.7.2 send command to card (receive multiple data blocks and status) this sequence sends a read data command to the card. the card sends back a response token on the cmd line, while at the same time sending the data on the data lines. the sequence is set to receive blockcount data packets from the card. no stop command is sent as part of this sequence. cmdbitcount = 46 if(wide_shift_mode) wide_shift_mask = 0x400000; else wide_shift_mask = 0; flashmediacmd2 = 0x460000 + cmdbitcount flashmediacmd1 = 0x040000 + wide_shift_mask while(cmdbitcount > 0) { if(flashmediadata2 empty) { read flashmediadata2 cmdbitcount = cmdbitcount - 32; } } wait until ((flashmediacmd2 & 0xffff) == 0) or wait until (shiftbusy2fall event) /* start receiving data and status */ respbitcount = 46 or 134; blockcount = flashmedia interface motorola section 13 ide and flashmedia interface 13-25 while(blockcount > 0) { -- start reception of new block databitcount = 13-26 mcf5249um motorola flashmedia interface /* second one more suitable for interrupt driven */ wait until ((flashmediacmd2 & 0xffff) == 0) or wait until (shiftbusy2fall event) /* receive status from host */ wait until (shiftbusy2rise event) or wait until ((flashmediastatus & 8)!= 0) respbitcount = 46 or 134 /* depends on command */ flashmediacmd2 = 0xc00000 + respbitcount; while(respbitcount > 0) { if(flashmediadata2 full) { read data from flashmediadata2 respbitcount:= respbitcount - 32; } } } /* start sending data to card */ blockcount:= motorola section 14 dma controller module 14-1 section 14 dma controller module the direct memory access (dma) controller module quickly and efficiently moves blocks of data with minimal processor overhead. the dma module, shown in figure 14-1 , provides four channels that allow byte, word, or longword operand transfers. these transfers should be dual address to on-chip devices; such as the uart, sdram controller, and audio module. figure 14-1 dma signal diagram mux arbitration/ interface datapath control internal internal current channel channel mux control external external registered attributes datapath control sar dar bcr cntrl status channel0 interrupts sar dar bcr cntrl status channel1 sar dar bcr cntrl status channel2 sar dar bcr cntrl status channel3 bus requests attributes master write bus data bus read bus data bus signals bus address bus size channel enables requests 14-2 mcf5249um motorola dma signal description 14.1 dma features four fully independent programmable dma controller module channels/bus modules auto-alignment feature for source or destination accesses dual-address transfer capability programmable hardware request lines from the audio module and uart going to all 4 dma channels channels 2 and 3 request signals may be connected to the interrupt lines of uart0 and uart1, respectively channel arbitration on transfer boundaries data transfers in 8-, 16-, 32-, or 128-bit blocks using a 16-byte buffer burst and cycle steal transfers independent transfer widths for source and destination independent source and destination address registers data transfer in two clocks 14.2 dma signal description this section contains a brief description of the dma module signals that provide handshake control for either a source or destination external device. table 14-1 summarizes these handshake signals . 14.2.1 dma request these internal signals, request[3:0], are dma request inputs. there is one input for each of the 4 dma channels. the request sources are selectable by programming the dmaroute register. each dma channel is programmable individually. the internal signals are asserted by a peripheral device to request an operand transfer between that peripheral and memory. 14.3 dma module overview the dma controller module usually transfers data at rates much faster than the coldfire core under software control can handle. the term dma refers to the ability for a peripheral device to access memory in a system in the same manner as a microprocessor. dma operations can greatly increase overall system performance. the dma module consists of four independent channels. the term dma is used throughout this section to reference any of the four channels, as they are all functionally equivalent. it is impossible to implicitly address all four dma channels at the same time. the mcf5249 on-chip peripherals do not support the single-address transfer mode. dma requests can be generated by the processor writing to the start bit in the dma control register or generated by an on-chip peripheral device asserting one of the request signals. the processor can program the amount of bus bandwidth allocated for the dma for each channel. the dma channels support continuous and cycle-steal transfer modes. table 14-1 dma signals signal name direction description request[3:0] in dma request signal coming from internal modules dma programming model motorola section 14 dma controller module 14-3 note: request[3:0] are internal signals only. the dma controller supports dual-address transfers. in dual-address mode, the dma channel supports 32 bits of address and 32 bits of data. dual-address transfers can be initiated by either an processor request using the start bit or by an internal peripheral device using the request signal. two bus transfers occur in this mode, a read from a source device and a write to a destination device (see figure 14-2 ). any operation involving the dma module follows the same three basic steps: 1. channel initialization step ? the dma channel registers are loaded with control information, address pointers, and a byte transfer count. also, the dmaroute register is programmed to control the source of request[3:0] 2. data transfer step ? the dma accepts requests for operand transfers and provides addressing and bus control for the transfers. 3. channel termination step ? this occurs after operation is complete. the channel indicates the status of the operation in the channel status register. figure 14-2 dual address transfer 14.4 dma programming model the registers of each channel are mapped into memory as shown in table 14-2 . the dma control module registers determine the operation of the dma controller module. this section describes each of the internal registers and its bit assignment. note: there is no mechanism for preventing a write to a control register during dma transfer. dma memory or memory- mapped peripheral memory or memory- mapped peripheral 14-4 mcf5249um motorola dma programming model note: table 14-2 is for bcr24bit = 0. table 14-6 shows the difference in the memory map when bcr24bit = 1. table 14-2 memory map dma channel 0 dma channel address [31:24] [23:16] [15:8] [7:0] mbar2+$188 dmaroute - request source control channel 0 mbar+$300 source address register 0 mbar+$304 destination address register 0 mbar+$308 dma control register 0 mbar+$30c byte count register 0 reserved mbar+$310 status register 0 reserved mbar+$314 interrupt vector register 0 reserved table 14-3 memory map dma channel 1 dma channel address [31:24] [23:16] [15:8] [7:0] channel 1 mbar+$340 source address register 1 mbar+$344 destination address register 1 mbar+$348 dma control register 1 mbar+$34c byte count register 1 reserved mbar+$350 status register 1 reserved mbar+$354 interrupt vector register 1 reserved table 14-4 memory map dma channel 2 dma channel address [31:24] [23:16] [15:8] [7:0] channel 2 mbar+$380 source address register 2 mbar+$384 destination address register 2 mbar+$388 dma control register 2 mbar+$38c byte count register 2 reserved mbar+$390 status register 2 reserved mbar+$394 interrupt vector register 2 reserved table 14-5 memory map dma channel 3 dma channel address [31:24] [23:16] [15:8] [7:0] channel 3 mbar+$3c0 source address register 3 mbar+$3c4 destination address register 3 mbar+$3c8 dma control register 3 mbar+$3cc byte count register 3 reserved mbar+$3d0 status register 3 reserved mbar+$3d4 interrupt vector register 3 reserved dma programming model motorola section 14 dma controller module 14-5 14.4.1 request source selection the routing control register (dmaroute) controls where the non-processor dma request for the four dma channels is coming from. table 14-9 describes dma route fields. table 14-6 memory map (dma controller registers ?bcr24bit = 1) dma channel address offset from mbar [31:24] [23:0] channel 0 30c reserved byte count register 0 channel 1 34c reserved byte count register 1 channel 2 38c reserved byte count register 2 channel 3 3cc reserved byte count register 3 table 14-7 dmaroute register bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field dma3req dma2req reset00000000 00000000 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w bits1514131211109876543210 field dma1req dma0req reset00000000 00000000 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w mbar2 + $188) table 14-8 dmaroute register fields dmaroute bits field name dma channe l 31:24 dma3req(7:0) dma3 23:16 dma2req(7:0) dma2 15:8 dma1req(7:0) dma1 7:0 dma0req(7:0) dma0 14-6 mcf5249um motorola dma programming model table 14-9 dma3req field definition dma3req(7:0) field value request source for dma block 0x80 dma3: uart 1 uart1 0x00 reserved 0x01 reserved 0x02 reserved 0x03 reserved 0x04 reserved 0x05 reserved 0x06 reserved 0x07 reserved 0x08 reserved 0x09 reserved 0x0a reserved 0x0b reserved 0x0c reserved 0x0d reserved 0x0e reserved 0x0f reserved table 14-10 dma2req field definition dma2req(7:0) field value request source for dma block 0x80 dma2: uart 0 uart0 0x00 reserved 0x01 reserved 0x02 reserved 0x03 reserved 0x04 reserved 0x05 reserved 0x06 reserved 0x07 reserved 0x08 reserved dma programming model motorola section 14 dma controller module 14-7 0x09 reserved 0x0a reserved 0x0b reserved 0x0c reserved 0x0d reserved 0x0e reserved 0x0f reserved table 14-11 dma1req field definition dma1req(7:0) field value request source for dma block 0x80 dma1: audio source 1 audio 0x81 dma1: audio source 2 audio 0x00 reserved 0x01 reserved 0x02 reserved 0x03 reserved 0x04 reserved 0x05 reserved 0x06 reserved 0x07 reserved 0x08 reserved 0x09 reserved 0x0a reserved 0x0b reserved 0x0c reserved 0x0d reserved 0x0e reserved 0x0f reserved table 14-10 dma2req field definition dma2req(7:0) field value request source for dma block 14-8 mcf5249um motorola dma programming model 14.4.2 source address register the source address register (sar) is a 32-bit register containing the address from which the dma controller module requests data during a transfer. table 14-12 dma0req field definition dma0req(7:0) field value request source for dma block 0x80 dma0: audio source 1 audio 0x81 dma0: audio source 2 audio 0x00 reserved 0x01 reserved 0x02 reserved 0x03 reserved 0x04 reserved 0x05 reserved 0x06 reserved 0x07 reserved 0x08 reserved 0x09 reserved 0x0a reserved 0x0b reserved 0x0c reserved 0x0d reserved 0x0e reserved 0x0f reserved table 14-13 source address register (sar) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field sar3 1 sar3 0 sar2 9 sar2 8 sar2 7 sar2 6 sar2 5 sar2 4 sar2 3 sar2 2 sar2 1 sar2 0 sar1 9 sar1 8 sar1 7 sar1 6 reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field sar1 5 sar1 4 sar1 3 sar1 2 sar1 1 sar1 0 sar9 sar8 sar7 sar6 sar5 sar4 sar3 sar2 sar1 sar0 dma programming model motorola section 14 dma controller module 14-9 note: only part of the on-chip sram can be accessed by the dma. the memory controlled by rambar0 is not visible for dma. the memory controlled by rambar1 is visible for dma. as a result, the sar or dar address range cannot be programmed to on-chip sram0 memory, since the on-chip dmas cannot access on-chip sram0 as a source or destination. they can access sram1, however. 14.4.3 flashmedia data registers the destination address register (dar) is a 32-bit register containing the address to which the dma controller module sends data during a transfer. note: the mcf5249 on-chip dmas must be careful when transferring data to cacheable memory since the on-chip dmas do not maintain cache coherency with the mcf5249 instruction cache. 14.4.4 byte count register the byte count register (bcr) is a 24-bit register containing the number of bytes remaining to be transferred for a given block. the offset within the memory map is based on the value of the bcr24bit bit in the mpark register of the sim module. see the following table for the bit locations. note: if the bcr24bit = 1, the upper 8 bits are loaded with zeros. the bcr decrements on the successful completion of the address phase of a write transfer in dual-address mode. the amount the bcr decrements is 1, 2, 4, or 16 for byte, word, longword, or line accesses, respectively. reset0000000000000000 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w mbar + $300), mbar+ $340, mbar + $380, mbar + $3c0) table 14-14 destination address register (dar) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field dar3 1 dar3 0 dar2 9 dar2 8 dar2 7 dar2 6 dar2 5 dar2 4 dar2 3 dar2 2 dar2 1 dar2 0 dar1 9 dar1 8 dar1 7 dar1 6 reset0000000000000000 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w bits 1514131211109876543210 field dar1 5 dar1 4 dar1 3 dar1 2 dar1 1 dar1 0 dar9 dar8 dar7 dar6 dar5 dar4 dar3 dar2 dar1 dar0 reset0000000000000000 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w mbar + $304, mbar + $344, mbar + $384, mbar + $3c4 table 14-13 source address register (sar) 14-10 mcf5249um motorola dma programming model the done bit dma status register ( figure 14-2 ) is set when the entire block transfer is complete. when a transfer sequence is initiated and the bcr contains a value that is not divisible by 16, 4, or 2 when the dma is configured for line, longword, or word transfers, respectively, the configuration error bit (ce) in the dma status register (dsr) is set and the transfer does not take place. refer to section 14.4.6 dma status register for more details. 14.4.5 dma control register the dma control register (dcr) sets the configuration of the dma controller module. depending on the state of the bcr24bit in the mpark register in the sim module, the dma control register looks slightly different. specifically, the at bit (dcr[15]) is included when bcr24bit = 1, providing greater flexibility in dma transfer acknowledge. table 14-15 byte count register (bcr)?bcr24bit = 1 bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field reserved bcr2 3 bcr2 2 bcr2 1 bcr2 0 bcr1 9 bcr1 8 bcr1 7 bcr1 6 reset 0 0 0 0 0 0 0 0 r/w r/w r/w r/w r/w r/w r/w r/w r/w bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field bcr1 5 bcr1 4 bcr1 3 bcr1 2 bcr1 1 bcr1 0 bcr9 bcr8 bcr7 bcr6 bcr5 bcr4 bcr3 bcr2 bcr1 bcr0 reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w mbar + $30c, mbar + $34c, mbar + $38c, mbar + $3cc table 14-16 byte count register (bcr)?bcr24bit = 0 bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field bcr1 5 bcr1 4 bcr1 3 bcr1 2 bcr1 1 bcr1 0 bcr9 bcr8 bcr7 bcr6 bcr5 bcr4 bcr3 bcr2 bcr1 bcr0 reset r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field reserved reset r/w mbar + $30c, mbar + $34c, mbar + $38c, mbar + $3cc table 14-17 dma control register (dcr)?bcr24bit = 0 bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field int eext cs aa bwc daa s_rw sinc ssize dinc dsize start reset dma programming model motorola section 14 dma controller module 14-11 r/w r/w bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field reserved reset r/w mbar + $308, mbar + $348, mbar + $388, mbar + $3c8 table 14-18 dma control bit descriptions bit name description int the interrupt on completion of transfer field determines whether an interrupt is generated at the completion of the transfer or occurrence of an error condition. 0 = no interrupt is generated. 1 = internal interrupt signal is enabled. eext enable peripheral request. collision could occur between the start bit and the request signal when eext = 1. therefore, caution should be exercised when initiating a dma transfer with the start bit while eext = 1. 0 = peripheral request is ignored. 1 = enables peripheral request to initiate transfer. internal request is always enabled. it is initiated by writing a 1 to the start bit cs cycle steal. 0 = dma continuous make read/write transfers until the bcr decrements to zero. 1 = forces a single read/write transfer per request. the request may be processor by setting the start bit, or periphery by asserting the request signal. (can be generated by the processor.) aa the auto-align bit and the size bits determine whether the source or destination is auto-aligned. auto alignment means that the accesses are optimized based on the address value and the programmed size. for more information, see section 14.7.2 data transfer . 0 = auto-align disabled. 1 = if the ssize bits indicate a larger or equivalent transfer size with respect to dsize, then the source accesses are auto-aligned. if the dsize bits indicate a larger transfer size than ssize, then the destination accesses are auto-aligned. source alignment takes precedence over destination alignment. if auto- alignment is enabled, the appropriate address register increments, regardless of the state of dinc or sinc. table 14-17 dma control register (dcr)?bcr24bit = 0 14-12 mcf5249um motorola dma programming model bwc the three bandwidth control bits are decoded for internal bandwidth control. when the byte count reaches any multiple of the programmed bwc boundary, the request signal to the internal arbiter is negated until data access completes. this enables the arbiter to give another device access to the bus. table 14-19 shows the encoding for these bits. when the bits are cleared, the dma does not negate its request. the 000 encoding asserts a priority signal when the channel is active, signaling that the transfer has been programmed for a higher priority. when the bcr reaches a multiple of the values shown in the table, the bus is relinquished. for example, if bwc = 001 (512 bytes or value of 0x0200), bcr24bit = 0, and the bcr is set to 0x1000, the bus is relinquished after bcr values of 0x2000, 0x1e00, 0x1c00, 0x1a00, 0x1800, 0x1600, 0x1400, 0x1200, 0x1000, 0x0e00, 0x0c00, 0x0a00, 0x0800, 0x0600, 0x0400, and 0x0200. in another example, bwc = 110, bcr24bit = 0, and the bcr is set to 33000. the bus is relinquished after transferring 232 bytes, because the bcr is at 32768, which is a multiple of 16384. s_rw reserved, must be set to 0. daa dual address access. 0 = the dma channel is in dual-address mode. 1 = reserved sinc the source increment bit determines whether the source address increments after each successful transfer. 0 = no change to the sar after a successful transfer. 1 = the sar increments by 1, 2, 4, or 16; depending upon the size of the transfer. table 14-18 dma control bit descriptions bit name description table 14-19 bwc encoding bwc block size bcr24bit = 0 bcr24bit = 1 000 dma has priority 001 512 16384 010 1024 32768 011 2048 65536 100 4096 131072 101 8192 262144 dma programming model motorola section 14 dma controller module 14-13 14.4.6 dma status register the 8-bit dma status register (dsr) indicates the status of the dma controller module. the dma controller module, in response to an event, writes to the appropriate bit in the dsr. only a write to the done bit (dsr[0]) results in action. setting the done bit creates a single-cycle pulse which resets the channel, thus clearing all bits in the register. the done bit is set at the completion of a transfer or during the transfer to abort the access. table 14-22 shows the detailed structure of the dma status register. ssize the source size field determines the data size of the source bus cycle for the dma control module. table 14-20 shows the encoding for this field. dinc the destination increment bit determines whether the destination address increments after each successful transfer. 0 = no change to the dar after a successful transfer. 1 = the dar increments by 1, 2, 4, or 16; depending upon the size of the transfer. dsize the destination size field determines the data size of the destination bus cycle for the dma controller module. table 14-21 shows the encoding for this field. start start transfer. 0 = dma inactive. 1 = the dma begins the transfer in accordance to the values in the control registers. this bit is self-clearing after one clock and is always read as logic 0. table 14-18 dma control bit descriptions bit name description table 14-20 ssize encoding ssize transfer size 00 longword 01 byte 10 word 11 line table 14-21 dsize encoding ssize transfer size 00 longword 01 byte 10 word 11 line 14-14 mcf5249um motorola dma programming model table 14-22 dma status register (dsr) bits 7 6 5 4 3 2 1 0 field ? ce bes bed ? req bsy done reset 0 0 0 1 1 1 r/w r/w r/w r/w r/w r/w r/w mbar + $310, mbar + $350, mbar + $390, mbar + $3d0 table 14-23 dma status bit descriptions bit name description bit 7 reserved ce a configuration error results when either the number of bytes represented by the bcr is not consistent with the requested source or destination transfer size. configuration error can also result from the sar or dar containing an address that does not match the requested transfer size for the source or destination. the bit is cleared during a hardware reset or by writing a one to dsr[done]. 0 = no configuration error exists. 1 = a configuration error has occurred. bes bus error on source. 0 = no bus error occurred. 1 = the dma channel terminated with a bus error either during the read portion of a transfer. bed bus error on destination. 0 = no bus error occurred. 1 = the dma channel terminated with a bus error during the write portion of a transfer. bit 3 reserved req request 0 = there is no request pending or the channel is currently active. the bit is cleared when the channel is selected. 1 = the dma channel has a transfer remaining and the channel is not selected. bsy busy 0 = dma channel is inactive. this bit is cleared when the dma has finished the last transaction. 1 = this bit is set the first time the channel is enabled after a transfer is initiated. transfer request generation motorola section 14 dma controller module 14-15 14.4.7 dma interrupt vector register the dma interrupt vector register (divr) is an 8-bit register, which is driven out onto the bus in response to an internal acknowledge cycle. 14.5 transfer request generation the dma channel supports processor and periphery requests. bus utilization can be minimized for either processor or periphery request by selecting between cycle-steal and continuous modes. the dcr[eext] field determines the request-generation method for each channel. 14.5.1 cycle-steal mode the dma is in cycle-steal mode if the cs field (dcr[29]) is set. in this mode, only one complete transfer from source to destination takes place for each request. depending on the state of the eext field (dcr[30]), the request can be either processor or peri phery. processor request is selected by setting the start bit (dcr[16}). periphery request is initiated by asserting the request signal while the eext bit is set. 14.5.2 continuous mode the dma is in continuous mode if the cs field (dcr[29]) is cleared. after an internal or external request is asserted, the dma continuously transfers data until the byte count register (bcr) reaches zero or the done bit (dsr[0]) is set. the continuous mode can operate at maximum or limited rate. the maximum rate of transfer can be achieved if the bandwidth control bwc field (dcr[27:25]) is programmed to 000. then the active dma channel continues until the bcr decrements to zero or the done bit is set. done the transaction done bit may be read or written and is set when all dma controller module transactions have completed normally, as determined by the transfer count and error conditions. when the bcr reaches zero, done is set at the successful conclusion of the final transfer. writing a 1 to this bit clears all dma status bits and therefore can be used as an interrupt handler to clear the dma interrupt and error bits. the done bit can also be used to abort a transfer in progress by resetting the status bits. the done bit is self clearing. therefore, writing a 0 to it has no effect. 0= writing or reading a 0 has no effect whatsoever. 1= dma transfer completed. table 14-24 dma interrupt vector register (divr) bits 7 6 5 4 3 2 1 0 field interrupt vector bits reset00001111 r/w r/w r/w r/w r/w r/w r/w r/w r/w mbar + $314, mbar + $354, mbar + $394, mbar + $3d4 table 14-23 dma status bit descriptions bit name description 14-16 mcf5249um motorola data transfer modes a limited rate can be achieved by programming the bwc field to any value other than 000. the dma performs the specified number of transfers, then relinquishes control of the bus. the dma negates its internal bus request on the last transfer before the bcr reaches a multiple of the boundary specified in the bwc field. on transfer completion, the dma asserts its bus request again to regain bus ownership at the earliest opportunity, as determined by the internal bus arbiter. the minimum time that the dma loses bus control is one bus cycle. 14.6 data transfer modes each dma channel supports dual-address transfers. the dual-address transfer mode consists of a source operand read and a destination operand write. 14.6.1 dual-address transaction the dma controller module begins a dual-address transfer sequence when the daa bit (dcr[24]) is cleared during a dma request. if no error condition exists, the req bit (dsr[2]) is set. 14.6.1.1 dual-address read the dma controller module will drive the value in the source address register (sar) onto the internal address bus. if the sinc bit (dcr[22]) is set, then the sar increments by the appropriate number of bytes upon a successful read cycle. when the appropriate number of read cycles completes successfully, the dma initiates the write portion of the transfer. in the event of a termination error, the bes (dsr[5]) and done bit (dsr[0]) are set and no further dma transactions take place. 14.6.1.2 dual-address write the dma controller module drives the value in the destination address register (dar) onto the address bus. if the dinc bit (dcr[19]) is set, then the dar increments by the appropriate number of bytes at the completion of a successful write cycle. the byte count register (bcr) decrements by the appropriate number of bytes. the done bit (dsr[0]) is set when the bcr reaches zero. if the bcr is greater than zero, then another read/write transfer is initiated. if the byte count register (bcr) is a multiple of the programmed bandwidth control (bwc), then the dma request signal is negated until termination of the bus cycle to allow the internal arbiter to switch masters. in the event of a termination error, the bes (dsr[5]) and done bit (dsr[0]) are set and no further dma transactions takes place. 14.7 dma transfer functional description in the following section, the term dma request implies that the start bit (dcr[16]) is set or the eext bit (dcr[30]) is set, followed by assertion of request. the start bit is cleared when the channel begins an internal access. before initiating a transfer, the dma controller module verifies that the source size (ssize = dsc[21:20]) and destination size (dsize = dsr[18:17]) for dual-address access are consistent with the source address and destination address. the ce bit is also set if inconsistency is found between the destination size and the source size in the bcr for dual-address access. if a misalignment is detected, no transfer occurs and the configuration error bit (ce = dsr[6]) is set. depending on the configuration of the dcr, an interrupt event may be issued when the ce bit is set. dma transfer functional description motorola section 14 dma controller module 14-17 note: if the auto-align bit (aa = dcr[28]) is set, error checking is performed on the appropriate registers only. a read/write transfer refers to a dual-address access in which a number of bytes are read from the source address and written to the destination address. the number of bytes in the transfer is determined by the larger of the sizes specified by the source and destination size encoding. see table 14-20 and table 14-21 . the source and destination address registers (sar and dar) increment at the completion of a successful address phase. the bcr decrements at the completion of a successful address write phase. a successful address phase occurs when a valid address request is not held by the arbiter. 14.7.1 channel initialization and startup before starting a block transfer operation, the channel registers must be initialized with information describing the channel configuration, request-generation method, and data block. this initialization is accomplished by programming the appropriate information into the channel registers. 14.7.1.1 channel prioritization the four dma channels are prioritized in ascending order (channel 0 having highest priority and channel 3 having the lowest) or as determined by the bwc bits in the dcr. if the bwc bits for a dma channel are set to 000, then that channel has priority over the channel immediately preceding it. for example, if dma channel 3 has the bwc bits set to 000, it has priority over dma channel 2 but not over dma channel 1. this is assuming that dma channel 2 has something other than all zeroes in the bwc bits. another example would be the case where the bwc bits in only dma 2 and dma 1 are all zeroes. in this case, dma 1 would have priority over dma 0 and dma 2. the bwc bits being zero in dma 2 in this case have no effect on prioritization. in the case of simultaneous external requests, the prioritization is either ascending or as determined by each channels bwc bits as described in the previous paragraphs. 14.7.1.2 programming the dma the following are some general comments on programming the dma: no mechanism exists for preventing writes to control registers during dma accesses if the bwc of sequential channels are equivalent, channel priority is in ascending order the sar is loaded with the source (read) address. if the transfer is from a peripheral device to memory, the source address is the location of the peripheral data register. if the transfer is from memory to a peripheral device or memory to memory, the source address is the starting address of the data block. this address can be any byte address. the dar should contain the destination (write) address. if the transfer is from a peripheral device to memory, or memory to memory, the dar is loaded with the starting address of the data block to be written. if the transfer is from memory to a peripheral device, the dar is loaded with the address of the peripheral data register. this address can be any byte address. the manner in which the sar and dar change after each cycle depends on the values in the dcr ssize and dsize fields and the sinc and dinc bits, and the starting address in the sar and dar. if programmed to increment, the increment value is 1, 2, 4, or 16 for byte, word, longword, or line operands, respectively. if the address register is programmed to remain unchanged (no count), the register is not incremented after the operand transfer. 14-18 mcf5249um motorola dma transfer functional description the bcr must be loaded with the number of byte transfers that are to occur. this register is decremented by 1, 2, 4, or 16 at the end of each transfer. the dsr must be cleared for channel startup. once the channel has been initialized, it is started by writing a one to the start bit in the dcr or asserting the request signal, depending on the status of the eext bit in the dcr. programming the channel for processor request causes the channel to request the bus and start transferring data immediately. if the channel is programmed for periphery request, request must be asserted before the channel requests the bus. if any fields in the dcr are modified while the channel is active, that change is effective immediately. to avoid any problems with changing the setup for the dma channel, a 1 should be written to the done bit in the dsr to stop the dma channel. 14.7.2 data transfer 14.7.2.1 periphery request operation all channels can initiate transfers to/from a periphery module by means of request[3:0]. source where request is coming from is programmed in register dmaroute. if the eext bit (dcr[30]) is set, when a request is asserted, the dma initiates a transfer provided the channel is idle. if the cs (cycle steal) bit is set, the read/write transaction on the bus is limited to a single transfer. if the cs bit is clear, multiple read/write transfers can occur on the bus as programmed. request does not need to be negated until the done bit (dsr[0]) is set. 14.7.2.2 auto alignment this feature allows for block transfers to occur at the optimum size based on the address, byte count, and programmed size. to use this feature, aa in the dcr must be set. the source is auto-aligned when the ssize bits indicate a larger transfer size compared to dsize. source alignment takes precedence over the destination when the source and destination sizes are equal. otherwise, the destination is auto-aligned. the address register that is chosen for alignment increments regardless of the value of the increment bit. configuration error checking is performed on the registers that are not chosen for alignment. if the bcr contains a value greater than 16, the address will determine the size of the transfer. single byte, word or longword transfers will occur until the address is aligned to the programmed size boundary, at which time the programmed size accesses begin. when the bcr is less than 16 at the beginning of a read/write transfer, the number of bytes remaining will dictate the transfer size, longword, word or byte. for example: aa = 1, sar = $0001, bcr = $00f0, ssize = 00 (longword) and dsize = 01 (byte), because the ssize > dsize, the source is auto-aligned. error checking is performed on the destination registers. the sequence of accesses is as follows: 1. read byte from $0001?write byte, increment sar 2. read word from $0002?write 2 bytes, increment sar 3. read long word from $0004?write 4 bytes, increment sar 4. repeat longwords until sar = $00f0 5. read byte from $00f0?write byte, increment sar. if dsize is set to another size, then the data writes are optimized to write the largest size allowed based on the address, but not exceeding the configured size. dma transfer functional description motorola section 14 dma controller module 14-19 14.7.2.3 bandwidth control this feature makes provision to force the dma off the bus to allow another master access. bus arbiter design was simplified by making arbitration programmable. the decode of the dcr[bwc] field provides 7 levels of block transfer sizes. if the bcr decrements to a value that is a multiple of the decode of the bwc, the dma bus request negates until termination of the bus cycle. should a request be pending, the arbiter may then choose to switch the bus to another master. if auto-alignment is enabled (dcr[aa] = 1), the bcr may skip over the programmed boundary. in this case, the dma bus request will not be negated. if the bwc = 000, the request signal will remain asserted until the bcr reaches zero. in addition, an internal signal will assert to indicate that the channel has been programmed to have priority. note: in this arbitration scheme, the arbiter can always force the dma to relinquish the bus. 14.7.3 channel termination 14.7.3.1 error conditions when the bus encounters a read or write cycle that terminates with an error condition, the appropriate bit of the dsr is set, depending on whether the bus cycle was a read (bes) or a write (bed). the dma transfers are then halted. if the error condition occurred during a write cycle, any data remaining in the internal holding register is lost. 14.7.3.2 interrupts if the int bit of the dcr is set, the dma will drive the appropriate slave bus interrupt signal. a processor can then read the dsr to determine if the transfer terminated successfully or with an error. the done bit of the dsr is then written with a 1 to clear the interrupt, along with clearing the done and error bits. 14-20 mcf5249um motorola notes motorola section 15 uart modules 15-1 section 15 uart modules the mcf5249 contains two universal asynchronous/synchronous receiver/transmitters (uarts) that act independently. each uart is clocked by the system clock. this section applies to both uarts, which are functionally identical. refer to section 15.4 register description and programming for addressing differences. each uart module, shown in figure 15-1 , consists of the following functional areas: serial communication channel 16-bit baud-rate timer internal channel control logic interrupt control logic figure 15-1 uart block diagram 15.1 module overview the mcf5249 contains two independent uart modules. features of each uart module include the following: uart clocked by the system clock or external clock (tin) full duplex asynchronous/synchronous receiver/transmitter channel quadruple-buffered receiver double-buffered transmitter independently programmable receiver and transmitter clock sources: programmable data format ? five to eight data bits plus parity ? odd, even, no parity, or force parity ? .563 to 2 stop bits in x16 mode (asynchronous)/1or 2 stop bits in synchronous mode internal channel control logic interrupt control logic 16-bit timer for baud rate generation serial communication channel cts rts rxd txd system clock tin (ext clk) 15-2 mcf5249um motorola programmable channel modes: ? normal (full duplex) ? automatic echo ? local loopback ? remote loopback automatic wakeup mode for multidrop applications four maskable interrupt conditions parity, framing, break, and overrun error detection false start bit detection line-break detection and generation detection of breaks originating in the middle of a character start/end break interrupt/status 15.1.1 serial communication channel the communication channel provides a full duplex asynchronous/synchronous receiver and transmitter using an operating frequency derived from the system clock or from an external clock tied to the tin pin. the transmitter accepts parallel data from the cpu; converts it to a serial bit stream; inserts the appropriate start, stop, and optional parity bits; then outputs a composite serial data stream on the channel transmitter serial data output (txd). refer to 15.3.2.1 transmitter for additional information. the receiver accepts serial data on the channel receiver serial data input (rxd); converts it to parallel format; checks for a start bit, stop bit, parity (if any), or any error condition; and transfers the assembled character onto the bus during read operations. the receiver can be polled or interrupt driven. refer to 15.3.2.2 receiver for additional information. 15.1.2 baud-rate generator/timer the 16-bit timer, clocked by the system clock, can function as an asynchronous x16 clock. in addition, an external clock can be tied to one of the tin pins of a mcf5249 timer for use as a synchronous or asynchronous clocking source for the uart. the baud-rate timer is part of each uart and not related to the coldfire timer modules. 15.1.3 interrupt control logic an internal interrupt request signal (irq ) notifies the mcf5249 interrupt controller of an interrupt condition. the output is the logical nor of all (as many as four) unmasked interrupt status bits in the uart interrupt status register (uisr). the uart interrupt mask register (uimr) can be programmed to determine which interrupts will be valid in the uisr. the uart module interrupt level in the mcf5249 interrupt controller is programmed external to the uart module. the uart can be configured to supply the vector from the uart interrupt vector register (uivr) or program the sim to provide an autovector when a uart interrupt is acknowledged. the interrupt level, priority within the level, and autovectoring capability can also be programmed in the sim register icr_u1. uart module signal definitions motorola section 15 uart modules 15-3 15.2 uart module signal definitions the following paragraphs contain a brief description of the uart module signals. figure 15-2 shows both the external and internal signal groups. note: the terms assertion and negation are used throughout this section to avoid confusion when dealing with a mixture of active-low and active-high signals. the term assert or assertion indicates that a signal is active or true, independent of the level represented by a high or low voltage. the term negate or negation indicates that a signal is inactive or false. 15.2.1 transmitter serial data output the multiplexed signals txd0/gpo27 and txd1/gpo28 can be programmed as general purpose outputs or transmitter serial data outputs. when used as transmitters, the output is held high ('?mark?' condition) when the transmitter is disabled, idle, or operating in the local loopback mode. data is shifted out on this signal on the falling edge of the clock source, with the least significant bit transmitted first. 15.2.2 receiver serial data input the multiplexed signals rxd0/gpi27 and rxd1/ gpi 28 can be programmed as general purpose inputs or receiver serial data inputs. when used as receivers, data received on this signal is sampled on the rising edge of the clock source, with the least significant bit received first . figure 15-2 external and internal interface signals internal control logic four-character receive buffer two-character transmit input port output port external interface signals interface to cpu uart module internal bus address bus control data 16-bit timer/ baud rate system clock irq cts rts rxd txd tin (extclk) generator buffer 15-4 mcf5249um motorola operation 15.2.3 request-to-send the request-to-send (rts ) pins rts0 / gpo 30 and rts1 / gpo31 are multiplexed with general purpose output pins. when programmed for rts , this active-low output signal can be programmed to be automatically negated and asserted by either the receiver or transmitter. when connected to the clear-to-send (cts ) input of a transmitter, this signal controls serial data flow. 15.2.4 clear-to-send the multiplexed signals cts0 / gpi30 and cts1 / gpi31 can be programmed as general purpose inputs or clear-to-send inputs. when programmed as (cts ), this active-low input is the clear-to-send input and can generate an interrupt on change-of-state. 15.3 operation the following sections describe the operation of the baud-rate generator, transmitter and receiver, and other operating modes of the uart module. 15.3.1 baud-rate generator/timer the timer references made here relative to clocking the uart are different than the mcf5249 timer module that is integrated on the bus of the coldfire core. the uart has a baud generator based on an internal baud-rate timer that is dedicated to the uart. the clock select register (uscr) can be programmed to enable the baud-rate timer or an external clock source from tin to generate baud rates. when the baud-rate timer is used, a prescaler supplies an asynchronous 32x clock source to the baud-rate timer. the baud-rate timer register value is programmed with the ubg1 and ubg2 registers. see 15.4.1.15 timer upper preload register (ubg1n) and 15.4.1.16 timer upper preload register 2 (ubg2n) for more information. an external tin clock source, when enabled in the uscr, can generate an x1 or x16 asynchronous or synchronous clock to the uart receiver and transmitter. figure 15-3 shows the relationship of clocking sources. figure 15-3 baud-rate timer generator diagram mcf5249 uart mcf5249 timer tin tout tin system clock x1 prescalar x16 prescalar timer output internal timer x32 prescalar tin baud rate baud rate output programmed in uscr operation motorola section 15 uart modules 15-5 15.3.2 transmitter and receiver operating modes the functional block diagram of the transmitter and receiver, including command and operating registers, is shown in figure 15-4 . the following paragraphs describe these functions in reference to this diagram. for detailed register information, refer to section 15.4 register description and programming . figure 15-4 transmitter and receiver functional diagram 15.3.2.1 transmitter the transmitter is enabled through the uart command register (ucr) located within the uart module. the uart module signals the cpu when it is ready to accept a character by setting the transmitter-ready bit (txrdy) in the uart status register (usr). functional timing information for the transmitter is shown in figure 15-5 . the transmitter converts parallel data from the cpu to a serial bit stream on txd. it automatically sends a start bit followed by the programmed number of data bits an optional parity bit the programmed number of stop bits the least significant bit is sent first. data is shifted from the transmitter output on the falling edge of the clock source. after the transmission of the stop bits, if a new character is not available in the transmitter holding register, the txd output remains in the high (mark condition) state, and the transmitter-empty bit (txemp) in the w r r/w r/w w r uart serial channel uart command register (ucr) external interface uart mode register 1 (umr1) uart mode register 2 (umr2) uart status register (usr) transmit holding register transmit shift register receiver holding register 1 receiver holding register 2 receiver holding register 3 receiver shift register transmit buffer (utb) (2 registers) receive buffer (urb) (4 registers) fifo txd rxd 15-6 mcf5249um motorola operation usr is set. transmission resumes and the txemp bit is cleared when the cpu loads a new character into the uart transmitter buffer (utb). if the transmitter receives a disable command, it continues operating until the character (if one is present) in the transmit-shift register is completely shifted out of transmitter txd. if the transmitter is reset through a software command, operation ceases immediately (refer to section 15.4.1.5 command registers (ucrn) ). the transmitter is re-enabled through the ucr to resume operation after a disable or software reset. figure 15-5 transmitter timing diagram if clear-to-send operation is enabled, cts must be asserted for the character to be transmitted. if cts is negated in the middle of a transmission, the character in the shift register is transmitted and following the completion of stop bits txd, enters in the mark state until cts is asserted again. if the transmitter is forced to send a continuous low condition by issuing a send-break command, the transmitter ignores the state of cts . users can program the transmitter to automatically negate the request-to-send (rts ) output on completion of a message transmission. if the transmitter is programmed to operate in this mode, rts must be manually asserted before a message is transmitted. in applications where the transmitter is disabled after transmission is complete and rts is appropriately programmed, rts is negated one bit time after the character in the shift register is completely transmitted. users must manually enable the transmitter by setting the enable-transmitter bit in the uart command register (ucr). c1 c2 c3 c6 c4 transmitter 4 enabled w w w w w w w w w internal module select txrdy txd cts 1 c1 c2 c3 c4 c5 c6 start 5 break stop break not transmitted negated since transmit buffer and shift register are empty (last character has been shifted out) notes: 1. timing shown for umr2[4]=1 2. timing shown for umr2[5]=1 3. cn=transmit 8-bit character 4. transmitter enable by configuring tcx bits in ucr (see table 11-9) 5. start break/stop break programmed by miscx bits in ucr (see table 11-8) disable 7 trans. manually asserted manually asserted by bit-set command rts 2 (w=write) operation motorola section 15 uart modules 15-7 15.3.2.2 receiver the receiver is enabled through the ucr located within the uart module. functional timing information for the receiver is shown in figure 15-6 . the receiver looks for a high-to-low (mark-to-space) transition of the start bit on rxd. when a transition is detected, the state of rxd is sampled each 16 clock for eight clocks, starting one-half clock after the transition (asynchronous operation) or at the next rising edge of the bit time clock (synchronous operation). if rxd is sampled high, the start bit is not valid and the search for the valid start bit repeats. if rxd is still low, a valid start bit is assumed and the receiver continues to sample the input at one-bit time intervals at the theoretical center of the bit. figure 15-6 receiver timing diagram this process continues until the proper number of data bits and parity (if any) is assembled and one stop bit is detected. data on the rxd input is sampled on the rising edge of the programmed clock source. the least significant bit is received first. the data is then transferred to a receiver holding register and the rxrdy bit in the usr is set. if the character length is less than eight bits, the most significant unused bits in the receiver holding register are cleared. the rx rdy bit in the usr is set at the one-half point of the stop bit. c1 c2 c3 c4 c5 c6 c7 c8 rxd receiver enabled c6, c7, c8 are lost due to receiver disabled rxrdy2(s ro) ffull2.5 (sr1) r r r r r r |status data| |status data| |status data| | | | c2 c3 c4 internal module select cs r r |status data| overrun (sr4) rts1 (op0) reset by command c5 lost notes: 1. timing shown for umr1[7]=1 2. timing shown for umr1[6]=0 3. cn = received 5-8 bit character uop1[0]=1 r = read 15-8 mcf5249um motorola operation after the stop bit is detected, the receiver immediately looks for the next start bit. however, if a nonzero character is received without a stop bit (framing error) and rxd remains low for one-half of the bit period after the stop bit is sampled, the receiver operates as if a new start bit is detected. the parity error (pe), framing error (fe), overrun error (oe), and received break (rb) conditions (if any) set error and break flags in the usr at the received character boundary and are valid only when the rxrdy bit in the usr is set. if a break condition is detected (rxd is low for the entire character including the stop bit), a character of all zeros is loaded into the receiver holding register and the receive break (rb) and rxrdy bits in the usr are set. the rxd signal must return to a high condition for at least one-half bit time before a search for the next start bit begins. the receiver will detect the beginning of a break in the middle of a character if the break persists through the next character time. when the break begins in the middle of a character, the receiver places the damaged character in the receiver first-in-first-out (fifo) stack and sets the corresponding error conditions and rxrdy bit in the usr. the break persists until the next character time, the receiver places an all-zero character into the receiver fifo, and sets the corresponding rb and rxrdy bits in the usr. interrupts can be enabled on receive break. 15.3.2.3 receiver fifo the fifo is used in the uart receiver buffer logic. the fifo consists of three receiver holding registers. the receive buffer consists of the fifo and a receiver shift register connected to the rxd (refer to figure 15-4 ). data is assembled in the receiver shift register and loaded into the top empty receiver holding register position of the fifo. thus, data flowing from the receiver to the cpu is quadruple buffered. in addition to the data byte, three status bits, parity error (pe), framing error (fe), and received break (rb) are appended to each data character in the fifo; overrun error (oe) is not appended. by programming the error-mode bit (err) in the channel?s mode register (umr1), status can be provided in character or block modes. the rxrdy bit in the usr is set whenever one or more characters are available to be read by the cpu. a read of the receiver buffer produces an output of data from the top of the fifo. after the read cycle, the data at the top of the fifo and its associated status bits are ?'popped,'? and the receiver shift register can add new data at the bottom of the fifo. the fifo-full status bit (ffull) is set if all three stack positions are filled with data. either the rxrdy or ffull bit can be selected to cause an interrupt. character and block modes are two error modes that can be selected within the umr. in the character mode, status provided in the usr is given on a character-by-character basis and thus applies only to the character at the top of the fifo. in the block mode, the status provided in the usr is the logical or of all characters coming to the top of the fifo since the last reset error command. a continuous logical or function of the corresponding status bits is produced in the usr as each character reaches the top of the fifo. the block mode is useful in applications where the software overhead of checking each character's error cannot be tolerated. in this mode, entire messages are received and only one data integrity check is performed at the end of the message. this mode has a data-reception speed advantage; however, each character is not individually checked for error conditions by software. if an error occurs within the message, the error is not recognized until the final check is performed, and no indication exists as to which message character is at fault. in either mode, reading the usr does not affect the fifo. the fifo is popped only when the receive buffer is read. the usr should be read prior to reading the receive buffer. if all three of the fifo receiver operation motorola section 15 uart modules 15-9 holding registers are full when a new character is received, the new character is held in the receiver shift register until a fifo position is available. if an additional character is received during this state, the contents of the fifo are not affected. however, the previous character in the receiver shift register is lost and the oe bit in the usr is set when the receiver detects the start bit of the new overrunning character. to support flow control capability, the receiver can be programmed to automatically negate and assert rts . when in this mode, the receiver automatically negates rts when a valid start bit is detected and the fifo is full. when a fifo position becomes available, the receiver asserts rts . using this mode of operation prevents overrun errors by connecting the rts to the cts input of the transmitting device. to use the rts signals on uart 2, the mcf5249 pin assignment register (par) in the sim must be set up to enable the corresponding i/o pins for these functions. if the fifo contains characters and the receiver is disabled, the cpu can still read the characters in the fifo. if the receiver is reset, the fifo and all receiver status bits, corresponding output ports, and interrupt request are reset. no additional characters are received until the receiver is re-enabled. 15.3.3 looping modes the uart can be configured to operate in various looping modes as shown in figure 15-7 . these modes are useful for local and remote system diagnostic functions. the modes are described in the following paragraphs with additional information available in section 15.4 register description and programming . switching between modes should only be done while the transmitter and receiver are disabled because the selected mode is activated immediately on mode selection, even if this occurs in the middle of character transmission or reception. in addition, if a mode is deselected, the device switches out of the mode immediately, except for automatic echo and remote echo loopback modes. in these modes, the deselection occurs just after the receiver has sampled the stop bit (this is also the one-half point). for automatic echo mode, the transmitter stays in this mode until the entire stop bit has been retransmitted. 15.3.3.1 automatic echo mode in this mode, the uart automatically retransmits the received data on a bit-by-bit basis. the local cpu-to-receiver communication continues normally but the cpu-to-transmitter link is disabled. while in this mode, received data is clocked on the receiver clock and retransmitted on txd. the receiver must be enabled but not the transmitter. instead, the transmitter is clocked by the receiver clock. because the transmitter is not active, the txemp and txrdy bits in usr are inactive and data is transmitted as it is received. received parity is checked but not recalculated for transmission. character framing is also checked but stop bits are transmitted as received. a received break is echoed as received until the next valid start bit is detected. 15.3.3.2 local loopback mode in this mode, txd is internally connected to rxd. this mode is useful for testing the operation of a local uart module channel by sending data to the transmitter and checking data assembled by the receiver. in this manner, correct channel operations can be assured. both transmitter and cpu-to-receiver communications continue normally in this mode. while in this mode, the rxd input data is ignored, the txd is held marking, and the receiver is clocked by the transmitter clock. the transmitter must be enabled but not the receiver. 15-10 mcf5249um motorola operation 15.3.3.3 remote loopback mode in this mode, the channel automatically transmits received data on the txd output on a bit-by-bit basis. the local cpu-to-transmitter link is disabled. this mode is useful for testing remote channel receiver and transmitter operation. while in this mode, the receiver clocks the transmitter. note: because the receiver is not active, the cpu cannot read received data. all status conditions are inactive. received parity is not checked and is not recalculated for transmission. stop bits are transmitted as received. a received break is echoed as received until the next valid start bit is detected. figure 15-7 looping modes functional diagram 15.3.4 multidrop mode the uart can be programmed to operate in a wakeup mode for multidrop or multiprocessor applications. functional timing information for the multidrop mode is shown in figure 15-8 . the mode is selected by setting bits 3 and 4 in uart mode register 1 (umr1). this mode of operation connects the master station to several slave stations (maximum of 256). in this mode, the master transmits an address character followed by a block of data characters targeted for one of the slave stations. the slave stations channel receivers are disabled; however, they continuously monitor the data stream sent out by the master station. when the master sends an address character, the slave receiver channel notifies its respective cpu by setting the rxrdy bit in the usr and generating an interrupt (if programmed to do so). each slave station cpu then compares the received address to its station address and enables its receiver if it wants to cpu rx tx cpu cpu rx rx tx tx (a) automatic echo (b) local loopback (c) remote loopback rxd input rxd input rxd input txd output txd output txd output disabled disabled disabled disabled disabled operation motorola section 15 uart modules 15-11 receive the subsequent data characters or block of data from the master station. slave stations not addressed continue to monitor the data stream for the next address character. data fields in the data stream are separated by an address character. after a slave receives a block of data, the slave station cpu disables the receiver and reinitiates the process. figure 15-8 multidrop mode timing diagram a transmitted character from the master station consists of a start bit, a programmed number of data bits, an address/data (a/d) bit flag, and a programmed number of stop bits. the a/d bit identifies the type of character being transmitted to the slave station. the character is interpreted as an address character if the a/d bit is set or as a data character if the a/d bit is cleared. the polarity of the a/d bit is selected by programming bit 2 of umr1. umr1 should also be programmed before enabling the transmitter and loading the corresponding data bits into the transmit buffer. in multidrop mode, the receiver continuously monitors the received data stream, regardless of whether it is enabled or disabled. if the receiver is disabled, it sets the rxrdy bit and loads the character into the receiver holding register fifo, provided the received a/d bit is a one (address tag). the character is discarded if the received a/d bit is a zero (data tag). if the receiver is enabled, all received characters are transferred to the cpu using the receiver holding register stack during read operations. in either case, the data bits are loaded into the data portion of the stack while the a/d bit is loaded into the status portion of the stack normally used for a parity error (usr bit 5). framing error, overrun error, and 15-12 mcf5249um motorola register description and programming break detection operate normally. the a/d bit takes the place of the parity bit; therefore, parity is neither calculated nor checked. messages in this mode can still contain error detection and correction information. one way to provide error detection, if 8-bit characters are not required, is to use software to calculate parity and append it to the 5-, 6-, or 7-bit character. 15.3.5 bus operation this section describes the operation of the bus during read, write, and interrupt- acknowledge cycles to the uart module. all uart module registers must be accessed as bytes. 15.3.5.1 read cycles the cpu accesses the uart module with 1 to 2 wait states because the core system clock is divided by 2 for the uart module. the uart module responds to reads with byte data on d[7:0]. reserved registers return logic zero during reads. 15.3.5.2 write cycles the cpu with zero wait states accesses the uart module. the uart module accepts write data on d[7:0]. write cycles to read-only registers and reserved registers complete in a normal manner without exception processing; however, the data is ignored. 15.3.5.3 interrupt acknowledge cycles the uart module can arbitrate for interrupt servicing and supply the interrupt vector when it has successfully won arbitration. the vector number must be provided if interrupt servicing is necessary; thus, the interrupt vector register (uivr) must be initialized. the interrupt vector number generated by the ivr is used if the autovector is not enabled in the sim interrupt control register (icr). if the uivr is not initialized and the icr is not programmed for autovector, a spurious interrupt exception is taken if interrupts are generated. this works in conjunction with the mcf5249 interrupt controller, which allows a programmable interrupt priority level (ipl) for the interrupt. 15.4 register description and programming this section contains a detailed description of each register and its specific function as well as flowcharts of basic uart module programming. 15.4.1 register description writing control bytes into the appropriate registers controls the uart operation. a list of uart module registers and their associated addresses is shown in table 15-1 . note: all uart module registers are accessible only as bytes. the contents of the mode registers (umr1 and umr2), clock-select register (ucsr), and the auxiliary control register (uacr) bit 7 should be changed only after the receiver/transmitter is issued a software reset command?i.e., channel operation must be disabled. be careful if the register contents are changed during receiver/transmitter operations because unpredictable results can occur. for the registers described in this section, the numbers above the register description represent the bit position in the register. the register description contains the mnemonic for the bit. the values as shown in the following tables are the values of those register bits after a hardware reset. a value of u indicates that the bit value is unaffected by reset. the read/write status is shown in the last line. register description and programming motorola section 15 uart modules 15-13 15.4.1.1 mode register 1 (umr1n) the umr1 controls some of the uart module configuration. this register can be read or written at any time and is accessed when the mode register pointer points to umr1. the pointer is set to umr1 by reset or by a set pointer command using the control register. after reading or writing umr1, the pointer points to umr2. table 15-1 uart module programming model uart 0 uart 1 register read (r/w = 1) register write (r/w = 0) mbar+$1c0 mbar+$200 mode register (umr1, umr2) mode register (umr1, umr2) mbar+$1c4 mbar+$204 status register (usr) clock-select register (ucsr) mbar+$1c8 mbar+$208 do not access 1 command register (ucr) mbar+$1cc mbar+$20c receiver buffer (urb) transmitter buffer (utb) mbar+$1d0 mbar+$210 input port change register (uipcr) auxiliary control register (uacr) mbar+$1d4 mbar+$214 interrupt status register (uisr) interrupt mask register (uimr) mbar+$1d8 mbar+$218 baud rate generator prescale msb (ubg1) baud rate generator prescale msb (ubg1) mbar+$1dc mbar+$21c baud rate generator prescale lsb (ubg2) baud rate generator prescale lsb (ubg2) do not access 1 mbar+$1f0 mbar+$230 interrupt vector register (uivr) interrupt vector register (uivr) mbar+$1f4 mbar+$234 input port register (uip) do not access 1 mbar+$1f8 mbar+$238 do not access 1 output port bit set cmd (uop1) 2 mbar+$1fc mbar+$23c do not access 1 output port bit reset cmd (uop0) 2 note: 1. this address is used for factory testing and should not be read. reading this location results in undesired effects and possible incorrect transmission or reception of characters. register c ontents can also be changed. note: 2. address-triggered commands. table 15-2 mode register 1 bits 7 6 5 4 3 2 1 0 field rxrts rxirq err pm1 pm0 pt b/c1 b/c0 reset00000000 r/w read/write supervisor or user addr mbar + $1c0 (umr10) mbar + $200 (umr11) 15-14 mcf5249um motorola register description and programming table 15-3 mode register 1 bit descriptions bit name description rxrts receiver request-to-send control 1 = on receipt of a valid start bit, rts is negated if the uart fifo is full. rts is reasserted when the fifo has an empty position available. 0 = the receiver has no effect on rts . the rts is asserted by writing a one to the output port bit set register (uop1) this feature can be used for flow control to prevent overrun in the receiver by using the rts output to control the cts input of the transmitting device. if both the receiver and transmitter are programmed for rts control, rts control is disabled for both because such a configuration is incorrect. rxirq on uart 2, r rxirq ? receiver interrupt select 1 = ffull is the source that generates irq 0 = rxrdy is the source that generates irq err the error mode bit controls the meaning of the three fifo status bits (rb, fe, and pe) in the usr. 1 = block mode?the values in the channel usr are the accumulation (i.e., the logical or) of the status for all characters coming to the top of the fifo since the last reset error status command for the channel was issued. refer to 15.4.1.5 command registers (ucrn) for more information on uart module commands. 0 = character mode?the values in the channel usr reflect the status of the character at the top of the fifo. err = 0 must be used to obtain the correct a/d flag information when in multidrop mode. pm1?pm0 the parity mode bits encode the type of parity used for the channel (see table 15-4 ). the parity bit is added to the transmitted character and the receiver performs a parity check on incoming data. these bits can alternatively select multidrop mode for the channel. pt the parity type bit selects the parity type if parity is programmed by the parity mode bits; if multidrop mode is selected, it configures the transmitter for data character transmission or address character transmission. table 15-4 lists the parity mode and type or the multidrop mode for each combination of the parity mode and the parity type bits. note: ?force parity low? means forcing a 0 parity bit. ?force parity high? forces a 1 parity bit. table 15-4 pmx and pt control bits pm1 pm0 parity mode pt parity type 0 0 with parity 0 even parity 0 0 with parity 1 odd parity 0 1 force parity 0 low parity 0 1 force parity 1 high parity 1 0 no parity x no parity register description and programming motorola section 15 uart modules 15-15 15.4.1.2 mode register 2 (umr2n) uart mode registers 2 (umr 2 n) control uart module configuration. umr 2n can be read or written when the mode register pointer points to it, which occurs after any access to umr 1 n. umr 2n accesses do not update the pointer. b/c1?b/c0 the bits per character bits select the number of data bits per character to be transmitted. the character length listed in table 15-5 does not include start, parity, or stop bits. table 15-6 mode register 2 bits 7 6 5 4 3 2 1 0 field cm txrts txcts sb reset00000000 r/w read/write supervisor or user addr mbar + $1c0 mbar + $200 table 15-3 mode register 1 bit descriptions bit name description table 15-5 b/cx control bits b/c1 b/c0 bits/character 00 5 bits 01 6 bits 10 7 bits 11 8 bits 15-16 mcf5249um motorola register description and programming table 15-7 mode register 2 bit descriptions bit name description cm channel mode. selects a channel mode. section 16.5.3, ?looping modes,? describes individual modes. 00 normal 01 automatic echo 10 local loop-back 11 remote loop-back txrts transmitter ready-to-send. controls negation of rts to automatically terminate a message transmission when the transmitter is disabled after completion of a transmission. attempting to program a receiver and transmitter in the same channel for rts control is not permitted and disables rts control for both. 0 the transmitter has no effect on rts. 1 when the transmitter is disabled after transmission completes, setting this bit automatically clears uop[rts] one bit time after any characters in the channel transmitter shift and holding registers are completely sent, including the programmed number of stop bits. txcts transmitter clear-to-send. if both txcts and txrts are enabled, txcts controls the operation of the transmitter. 0 cts has no effect on the transmitter. 1 enables clear-to-send operation. the transmitter checks the state of cts each time it is ready to send a character. if cts is asserted, the character is sent; if it is negated, the channel txd remains in the high state and transmission is delayed until cts is asserted. changes in cts as a character is being sent do not affect its transmission. register description and programming motorola section 15 uart modules 15-17 sb stop-bit length control. selects the length of the stop bit appended to the transmitted character. stop-bit lengths of 9/16th to 2 bits are programmable for 6?8 bit characters. lengths of 1 1/16th to 2 bits are programmable for 5-bit characters. in all cases, the receiver checks only for a high condition at the center of the first stop-bit position, that is, one bit time after the last data bit or after the parity bit, if parity is enabled. if an external 1x clock is used for the transmitter, clearing bit 3 selects one stop bit and setting bit 3 selects 2 stop bits for transmission. table 15-7 mode register 2 bit descriptions bit name description sb 5 bits 6 -8 bits 0000 1.063 0.563 0001 1.125 0.625 0010 1.188 0.688 0011 1.250 0.750 sb 5 bits 6 -8 bits 0100 1.313 0.813 0101 1.375 0.875 0110 1.438 0.938 0111 1.500 1.000 sb 5 bits 6 -8 bits 1000 1.563 1.563 1001 1.625 1.625 1010 1.688 1.688 1011 1.750 1.750 sb 5 bits 6 -8 bits 1100 1.813 1.813 1101 1.875 1.875 1110 1.938 1.938 1111 2.000 2.000 15-18 mcf5249um motorola register description and programming 15.4.1.3 status registers (usrn) the usr registers indicate the status of the characters in the receive fifo and the status of the transmitter and receiver. the rb, fe, and pe bits are cleared by the reset error status command in the ucr registers if the rb bit has not been read. also, rb, fe, pe and oe can also be cleared by reading the receive buffer (urb). table 15-8 status registers (usr0 and usr1) bits 7 6 5 4 3 2 1 0 field rb fe pe oe txemp txrdy ffull rxrdy reset00000000 r/w read/write supervisor or user addr mbar + $1c4 (usr0) mbar + $204 (usr1) table 15-9 status bit descriptions bit name description rb received break 1 = an all-zero character of the programmed length has been received without a stop bit. the rb bit is valid only when the rxrdy bit is set. a single fifo position is occupied when a break is received. additional entries into the fifo are inhibited until rxd returns to the high state for at least one-half bit time, which is equal to two successive edges of the internal or external clock x 1 or 16 successive edges of the external clock x 16. the received break circuit detects breaks that originate in the middle of a received character. however, if a break begins in the middle of a character, it must persist until the end of the next detected character time. 0 = no break has been received. fe framing error 1 = a stop bit was not detected when the corresponding data character in the fifo was received. the stop-bit check occurs in the middle of the first stop-bit position. the bit is valid only when the rxrdy bit is set. 0 = no framing error has occurred. pe parity error 1 = when the with-parity or force-parity mode is programmed in the umr1, the corresponding character in the fifo was received with incorrect parity. when the multidrop mode is programmed, this bit stores the received a/d bit. this bit is valid only when the rxrdy bit is set. 0 = no parity error has occurred. oe overrun error 1 = one or more characters in the received data stream have been lost. this bit is set on receipt of a new character when the fifo is full and a character is already in the shift register waiting for an empty fifo position. when this occurs, the character in the receiver-shift register and its break-detect, framing-error status, and parity error, if any, are lost. the reset-error status command in the ucr clears this bit. 0 = no overrun has occurred. register description and programming motorola section 15 uart modules 15-19 15.4.1.4 clock-select registers (uscrn) the ucsr registers select the internal clock (timer mode) or the external clock in synchronous or asynchronous mode. to use the timer mode for either the receiver and transmitter channel, program the ucsr registers to the value $dd. the transmitter and receiver can be programmed to different clock sources. txemp transmitter empty 1 = the transmitter has underrun (both the transmitter holding register and transmitter shift registers are empty). this bit is set after transmission of the last stop bit of a character if there are no characters in the transmitter-holding register awaiting transmission. 0 = the transmitter buffer is not empty. either a character is currently being shifted out or the transmitter is disabled. users can enable/disable the transmitter by programming the tcx bits in the ucr. txrdy transmitter ready 1 = the transmitter-holding register is empty and ready to be loaded with a character. this bit is set when the character is transferred to the transmitter shift register. this bit is also set when the transmitter is first enabled. characters loaded into the transmitter holding register while the transmitter is disabled are not transmitted. 0 = the cpu has loaded the transmitter-holding register or the transmitter is disabled. ffull fifo full 1 = three characters have been received and are waiting in the receiver buffer fifo. 0 = the fifo is not full but can contain as many as two unread characters. rxrdy receiver ready 1 = one or more characters have been received and are waiting in the receiver buffer fifo. 0 = the cpu has read the receiver buffer and no characters remain in the fifo after this read. table 15-10 clock select register (ucsrn) bits 7 6 5 4 3 2 1 0 field rcs3 rcs2 rcs1 rcs0 tcs3 tcs2 tcs1 tcs0 reset11011101 r/w write only addr mbar + $1c4 mbar + $204 table 15-9 status bit descriptions bit name description 15-20 mcf5249um motorola register description and programming 15.4.1.5 command registers (ucrn) the ucr supplies commands to the uart. multiple commands can be specified in a single write to the ucr if the commands are not conflicting. for ex ample, reset-transmitter and enable-transmitter commands cannot be specified in a single command. 15.4.1.6 miscellaneous commands bits misc3 through misc0 select a single command as listed in table 15-13 . table 15-11 clock select bit descriptions bit name description rcs3?rcs0 the receiver clock select bits select the clock source for the receiver channel. table 15-11 details the register bits necessary for each mode. tcs3?tcs0 the transmitter clock select bits determine the clock source of the uart transmitter channel. table 15-12 command register (ucrn) bits 7 6 5 4 3 2 1 0 field ? misc2 misc1 misc0 tc1 tc0 rc1 rc0 reset00000000 r/w write only addr mbar + $1c8 (ucr0) mbar + $208 (ucr1) table 15-13 miscx control bits misc2 misc1 misc0 command 0 0 0 no command 0 0 1 reset mode register pointer 0 1 0 reset receiver 0 1 1 reset transmitter rcs3 rcs2 rcs1 rcs0 mode 1 101timer 1 1 1 0 ext. clk. x 16 1 1 1 1 ext. clk. x 1 tcs3 tcs2 tcs1 tcs0 set 1 1 101timer 1 1 1 0 ext. clk. x 16 1 1 1 1 ext. clk. x 1 register description and programming motorola section 15 uart modules 15-21 15.4.1.6.1 reset mode register pointer the reset mode register pointer command causes the mode register pointer to point to umr1. 15.4.1.6.2 reset receiver the reset receiver command resets the receiver. the receiver is immediately disabled, the ffull and rxrdy bits in the usr are cleared, and the receiver fifo pointer is reinitialized. all other registers are unaltered. use this command instead of the receiver-disable command whenever the receiver configuration is changed (it places the receiver in a known state). 15.4.1.6.3 reset transmitter the reset transmitter command resets the transmitter. the transmitter is immediately disabled and the txemp and txrdy bits in the usr are cleared. all other registers are unaltered. use this command instead of the transmitter-disable command whenever the transmitter configuration is changed (it places the transmitter in a known state). 15.4.1.6.4 reset error status the reset error status command clears the rb, fe, pe, and oe bits in the usr. this command is also used in the block mode to clear all error bits after a data block is received. 15.4.1.6.5 reset break-change interrupt the reset break-change interrupt command clears the delta break (dbx) bit in the uisr. 15.4.1.6.6 start break the start break command forces txd low. if the transmitter is empty, the start of the break conditions can be delayed by as much as two bit times. if the transmitter is active, the break begins when transmission of the character is complete. if a character is in the transmitter shift register, the start of the break is delayed until the character is transmitted. if the transmitter holding register has a character, that character is transmitted before the break. the transmitter must be enabled for this command to be accepted. the state of the cts input is ignored for this command. 15.4.1.6.7 stop break the stop break command causes txd to go high (mark) within two bit times. characters stored in the transmitter buffer, if any, are transmitted. 15.4.1.7 transmitter commands bits tc1 and tc0 select a single command as listed in table 15-14 . misc2 misc1 misc0 command 1 0 0 reset error status 1 0 1 reset break-change interrupt 1 1 0 start break 111 stop break table 15-13 miscx control bits 15-22 mcf5249um motorola register description and programming 15.4.1.7.1 no action taken the ?no action taken? command causes the transmitter to stay in its current mode. if the transmitter is enabled, it remains enabled; if disabled, it remains disabled. 15.4.1.7.2 transmitter enable the ?transmitter enable? command enables operation of the channel's transmitter. the txemp and txrdy bits in the usr are also set. if the transmitter is already enabled, this command has no effect. 15.4.1.7.3 transmitter disable the ?transmitter disable? command terminates transmitter operation and clears the txemp and txrdy bits in the usr. however, if a character is being transmitted when the transmitter is disabled, the transmission of the character is completed before the transmitter becomes inactive. if the transmitter is already disabled, this command has no effect. 15.4.1.7.4 do not use do not use this bit combination because the result is indeterminate. 15.4.1.8 receiver commands bits rc1 and rc0 select a single command as listed in table 15-15 . 15.4.1.8.1 no action taken the ?no action taken? command causes the receiver to stay in its current mode. if the receiver is enabled, it remains enabled; if disabled, it remains disabled. 15.4.1.8.2 receiver enable the ?receiver enable? command enables operation of the channel's receiver. if the uart module is not in multidrop mode, this command also forces the receiver into the search-for-start-bit state. if the receiver is already enabled, this command has no effect. table 15-14 tcx control bits tc1 tc0 command 0 0 no action taken 0 1 transmitter enable 1 0 transmitter disable 1 1 do not use table 15-15 rcx control bits rc1 rc0 command 0 0 no action taken 0 1 receiver enable 1 0 receiver disable 1 1 do not use register description and programming motorola section 15 uart modules 15-23 15.4.1.8.3 receiver disable the ?receiver disable? command immediately disables the receiver. any character being received is lost. the command has no effect on the receiver status bits or any other control register. if the uart module is programmed to operate in the local loopback mode or multidrop mode, the receiver operates even though this command is selected. if the receiver is already disabled, this command has no effect. 15.4.1.8.4 do not use do not use this bit combination because the result is indeterminate. 15.4.1.9 receiver buffer registers (ubrn) the receiver buffer (urb) contains three receiver-holding registers and a serial shift register. the rxd pin is connected to the serial shift register while the holding registers act as a fifo. the cpu reads from the top of the stack while the receiver shifts and updates from the bottom of the stack when the shift register has been filled (see figure 15-4 ). 15.4.1.10 transmitter buffer registers (utbn) the transmitter buffer (utb) consists of two registers: the transmitter-holding register and the transmitter shift register (see figure 15-4 ). the holding register accepts characters from the bus master if the txrdy bit in the channel's usr is set. a write to the transmitter buffer clears the txrdy bit, inhibiting additional characters until the shift register is ready to accept more data. when the shift register is empty, it checks the holding register for a valid character to be sent (txrdy bit cleared). if a valid character is present, the shift register loads the character and reasserts the txrdy bit in the usr. writes to the transmitter buffer when the channel's uart status register (usr) txrdy bit is clear and when the transmitter is disabled have no effect on the transmitter buffer. table 15-16 receiver buffer (urbn) bits 7 6 5 4 3 2 1 0 field rb7 rb6 rb5 rb4 rb3 rb2 rb1 rb0 reset11111111 r/w read only addr mbar + $1cc mbar + $20c table 15-17 receiver buffer bit descriptions bit name description rb7?rb0 these bits contain the character in the receiver buffer. table 15-18 transmitter buffer (utbn) bits 7 6 5 4 3 2 1 0 field tb7 tb6 tb5 tb4 tb3 tb2 tb1 tb0 reset00000000 r/w write only addr mbar + $1cc mbar + $20c 15-24 mcf5249um motorola register description and programming 15.4.1.11 input port change registers uipcrn) the uipcr registers show the current state and the change-of-state for the cts pin. 15.4.1.12 auxiliary control registers (uacrn) the uart auxiliary control registers control the input enable. table 15-19 transmitter buffer bit descriptions bit name description tb7?tb0 these bits contain the character in the transmitter buffer. table 15-20 input port change register (uipcrn) bits 7 6 5 4 3 2 1 0 field resvd resvd resvd cos resvd resvd resvd cts reset00001111 r/w read only addr mbar + $1d0 mbar + $210 table 15-21 input port change bit descriptions bit name description bits 7, 6, 5, 3, 2, 1 reserved cos change-of-state 1 = a change-of-state (high-to-low or low-to-high transition), lasting longer than 25?50 s has occurred at the cts input. when this bit is set, the uart auxiliary control register (uacr) can be programmed to generate an interrupt to the cpu. 0 = no change-of-state has occurred since the last time the cpu read the uart input port change register (uipcr). a read of the uipcr also clears the uart interrupt status register (uisr)cos bit. cts current state starting two serial clock periods after reset, the cts bit reflects the state of the cts pin. if the cts pin is detected as asserted at that time, the cos bit is set, which initiates an interrupt if the input enable control (iec) bit of the uacr register is enabled. 1 = the current state of the cts input is logic one. 0 = the current state of the cts input is logic zero. register description and programming motorola section 15 uart modules 15-25 15.4.1.13 interrupt status registers (uisrn) the uisr registers provides status for all potential interrupt sources. the uart interrupt mask register (uimr) masks the contents of this register. if a flag in the uisr is set and the corresponding bit in uimr is also set, the internal interrupt output is asserted. if the corresponding bit in the uimr is cleared, the state of the bit in the uisr has no effect on the interrupt output. note: the uimr does not mask reading of the uisr. true status is provided regardless of the contents of uimr. a uart module reset clears the contents of uisr. . table 15-22 auxiliary control register (uacrn) bits 7 6 5 4 3 2 1 0 field-------iec reset00000000 r/w write only addr mbar + $1d0 (uacr0) mbar + $210 (uacr1) table 15-23 auxiliary control bit descriptions bit name description iec input enable control 1 = uisr bit 7 is set and generates an interrupt when the cos bit in the uart input port change register (uipcr) is set by an external transition on the cts input (if bit 7 of the interrupt mask register (uimr) is set to enable interrupts). 0 = setting the corresponding bit in the uipcr has no effect on uisr bit 7. table 15-24 interrupt status register (uisrn) bits 7 6 5 4 3 2 1 0 field cos ? ? ? ? db rxrdy txrdy reset00000000 r/w read only addr mbar + $1d4 (uisr0) mbar + $214 (uisr1) 15-26 mcf5249um motorola register description and programming 15.4.1.14 interrupt mask registers uimrn) the uimr registers select the corresponding bits in the uisr that cause an interrupt. by setting the bit, the interrupt is enabled. if one of the bits in the uisr is set and the corresponding bit in the uimr is also set, the internal interrupt output is asserted. if the corresponding bit in the uimr is zero, the state of the bit in the uisr has no effect on the interrupt output. the uimr does not mask the reading of the uisr. table 15-25 interrupt status bit descriptions bit name description cos change-of-state 1 = a change-of-state has occurred at the cts input and has been selected to cause an interrupt by programming bit 0 of the uacr. 0 = cos bit in the uipcr is not selected. db delta break 1 = the receiver has detected the beginning or end of a received break. 0 = no new break-change condition to report. refer to 15.4.1.5 command registers (ucrn) for more information on the reset break-change interrupt command. rxrdy receiver ready or fifo full umr1 bit 6 programs the function of this bit. it is a duplicate of either the ffull or rxrdy bit of usr. txrdy transmitter ready this bit is the duplication of the txrdy bit in usr. 1 = the transmitter holding register is empty and ready to be loaded with a character. 0 = the cpu loads the transmitter-holding register or the transmitter is disabled. characters loaded into the transmitter-holding register when txrdy=0 are not transmitted. table 15-26 interrupt mask register (uimrn) bits 7 6 5 4 3 2 1 0 field cos ? ? ? ? db ffull txrdy reset00000000 r/w write only addr mbar + $1d4 (uimr0) mbar + $214 (uimr1) register description and programming motorola section 15 uart modules 15-27 15.4.1.15 timer upper preload register (ubg1n) the ubg registers hold the eight most significant bits of the preload value the timer uses for providing a given baud rate. the minimum value that can be loaded on the concatenation of ubg1 with ubg2 is $0002. this register is write only and cannot be read by the cpu. the ubg1 address is mbar + $1d8 for uart0 and mbar + $218 uart1. 15.4.1.16 timer upper preload register 2 (ubg2n) the ubg2 register holds the eight least significant bits of the preload value the timer uses for providing a given baud rate. the minimum value that can be loaded on the concatenation of ubg1 with ubg2 is $0002. this register is write only and cannot be read by the cpu. the ubg2 address is mbar + $1dc for uart0 and mbar + $21c uart1. 15.4.1.17 interrupt vector registers (uivrn) the uivr registers contain the 8-bit vector number of the internal interrupt. table 15-27 interrupt mask bit descriptions bit name description cos change-of-state 1 = enable interrupt 0 = disable interrupt db delta break 1 = enable interrupt 0 = disable interrupt ffull fifo full 1 = enable interrupt 0 = disable interrupt txrdy transmitter ready 1 = enable interrupt 0 = disable interrupt table 15-28 interrupt vector register (uivrn) bits 7 6 5 4 3 2 1 0 field ivr7 ivr6 ivr5 ivr4 ivr3 ivr2 ivr1 ivr0 reset00001111 r/w supervisor or user addr mbar + $1f0 (uivr0) mbar + $230 (uivr1) 15-28 mcf5249um motorola register description and programming 15.4.1.18 input port registers (uipn) the uip registers show the current state of the cts input. 15.4.1.19 output port data registers (uop1n) the rts output is set by a bit set command (writing to uop1) and is cleared by a bit reset command (writing to uop0). table 15-29 interrupt vector bit descriptions bit name description ivr7?ivr0 the interrupt vector bits are an 8-bit number that indicates the offset from the base of the vector table where the address of the exception handler for the specified interrupt is located. the uivr is reset to $0f, which indicates an uninitialized interrupt condition. table 15-30 input port register (uipn) bits 7 6 5 4 3 2 1 0 field???????cts reset11111111 r/w read only addr mbar + $1f4 (uip0) mbar + $234 (uip1) table 15-31 interrupt vector bit descriptions bit name description cts current state 1 = the current state of the cts input is logic one. 0 = the current state of the cts input is logic zero. the information contained in this bit is latched and reflects the state of the input pin at the time that the uip is read. this bit has the same function and value as the uipcr bit 0. table 15-32 output port data registers (uop1n) bits 7 6 5 4 3 2 1 0 field rts reset??????? 0 r/w write only addr mbar + $1f8 (uop10) mbar + $238 (uop11) register description and programming motorola section 15 uart modules 15-29 15.4.2 programming figure 11-9 shows the basic interface software flowchart required for operation of the uart module. the routines are divided into these three categories: 1. uart module initialization 2. i/o driver 3. interrupt handling 15.4.2.1 uart module initialization the uart module initialization routines consist of sinit and chchk. sinit is called at system initialization time to check uart operation. before sinit is called, the calling routine allocates two words on the system stack. on return to the calling routine, sinit passes information on the system stack to reflect the status of the uart. if sinit finds no errors, the receiver and transmitter are enabled. the chchk routine performs the actual checks as called from the sinit routine. when called, sinit places the uart in the local loopback mode and checks for the following errors: transmitter never ready receiver never ready parity error incorrect character received 15.4.2.2 i/o driver example the i/o driver routines consist of inch and outch. inch is the terminal input character routine and obtains a character from the receiver. outch sends a character to the transmitter. 15.4.2.3 interrupt handling the interrupt-handling routine consists of sirq, which is executed after the uart module generates an interrupt caused by a change in break (beginning of a break). sirq then clears the interrupt source, waits table 15-33 output port data bit descriptions bit name description rts output port parallel output 1 = a write cycle to the opset address asserts the rts signal. 0 = this bit is not affected by writing a zero to this address. the output port bits are inverted at the pins so the rts set bit provides an asserted rts pin. table 15-34 output port data registers (uop0n) bits 7 6 5 4 3 2 1 0 field???????rts reset???????? r/w write only addr mbar + $1fc (uop00) mbar + $23c (uop01) 15-30 mcf5249um motorola uart module initialization sequence for the next change-in-break interrupt (end of break), clears the interrupt source again, then returns from exception processing to the system monitor. 15.5 uart module initialization sequence the following steps are required to properly initialize the uart module: command register (ucr) 1. reset the receiver and transmitter. 2. program the vector number for a uart module interrupt. interrupt mask register (uimr) 1. enable the desired interrupt sources. auxiliary control register (uacr) 1. initialize the input enable control (iec) bit. 2. select timer mode and clock source, if necessary. clock select register (ucsr) 1. select the receiver and transmitter clock. use timer as source, if required. mode register 1 (umr1) 1. if required, program operation of receiver ready-to-send (rxrts bit). 2. select receiver-ready or fifo-full notification (r/f bit). 3. select character or block-error mode (err bit). 4. select parity mode and type (pm and pt bits). 5. select number of bits per character (b/cx bits). mode register 2 (umr2) 1. select the mode of operation (cmx bits). 2. if required, program operation of transmitter ready-to-send (txrts bit). 3. if required, program operation of clear-to-send (txcts bit). 4. select stop-bit length (sbx bits). command register (ucr) 1. enable the receiver and transmitter. uart module initialization sequence motorola section 15 uart modules 15-31 figure 15-9 uart software flowchart (1 of 5) serial module initiate: channel interrupts call chchk save channel status any errors? assert request to send enable return y n chk1 enable sintr enable receiver 15-32 mcf5249um motorola uart module initialization sequence figure 15-10 uart software flowchart (2 of 5) chchk place channel in local loopback model enable transmitter clear status word is transmitter ready? waited too long? send character to tranxmitter set transmitter- never-ready flag a b has character been received? waited too long? n n y n n y set receiver- never-ready flag (note: in loopback mode transmitter must be enabled. (not receiver) txchk y y uart module initialization sequence motorola section 15 uart modules 15-33 figure 15-11 uart software flowchart (3 of 5) have framing error? set framing error flag have parity error? set parity error flag disable transmitter restore to original mode return ab get character from receiver same as transmitted character? set incorrect character flag b chrchk frchk prchk rstchn 15-34 mcf5249um motorola uart module initialization sequence figure 15-12 uart software flowchart (4 of 5) rte replace return address on system stack and monitor warm start address sirq was irq caused by beginning of a break? clear change -in-break status has end-of-break irq arrived yet? clear change-in-break status bit remove break character from receive fifo inch does channel a receiver have a character? place character in d0 return uart module initialization sequence motorola section 15 uart modules 15-35 figure 15-13 uart software flowchart (5 of 5) outch is transmitter ready? send character to transmitter return 15-36 mcf5249um motorola notes motorola section 16 queued serial peripheral interface (qspi) module 16-1 section 16 queued serial pe ripheral interface (qspi) module this section describes the queued serial peripheral interface (qspi) module. following a feature-set overview is a description of operation including details of the qspi?s internal ram organization. the section concludes with the programming model and a timing diagram. 16.1 overview the queued serial peripheral interface module provides a serial peripheral interface with queued transfer capability. it allows users to queue up to 16 transfers at once, eliminating cpu intervention between transfers. transfer rams in the qspi are indirectly accessible using address and data registers. the qspi is functionally similar to the qsm in the 68332. 16.2 features programmable queue to support up to 16 transfers without user intervention supports transfer sizes of 8 to 16 bits in 1-bit increments four peripheral chip-select lines for control of up to 15 devices baud rates from 134 kbps to 16.7 mbps at a cpu clock of 140 mhz programmable delays before and after transfers programmable clock phase and polarity supports wraparound mode for continuous transfers 16.3 module description the qspi module communicates with the integrated coldfire cpu using internal memory mapped registers located starting at mbar + $400. see also section 16.5, ?programming model .? a block diagram of the qspi module is shown in figure 16-1 . 16.3.1 interface and pins the module provides as many as 15 ports and a total of seven signals: qspi_dout, qspi_din, qspi_clk, qspi_cs [3:0]. peripheral chip-select signals, qspi_cs[3:0], are used to select an external device as the source or destination for serial data transfer. signals are asserted at a logic level corresponding to the value of the qspi_cs[3:0] bits in the command ram whenever a command in the queue is executed. more than one chip-select signal can be asserted simultaneously. although qspi_cs[3:0] will function as simple chip selects in most applications, up to 15 ports can be selected by decoding them with an external 4-to-16 decoder. 16-2 mcf5249um motorola module description figure 16-1 qspi block diagram note: qspi_clk and qspi_din are muxed with scl2 and sda2 (second i 2 c interface). the qspi function must be selected by setting the qspisel bit in the pllcr register. 16.3.2 internal bus interface because the qspi module only operates in master mode, the master bit in the qspi mode register (qmr[mstr]) must be set for the qspi to function properly. the qspi can initiate serial transfers but cannot respond to transfers initiated by other qspi masters. table 16-1 qspi input and output signals and functions signal name hi-z or actively driven function qspi data output (qspi_dout) configurable serial data output from qspi qspi data input (qspi_din) n/a serial data input to qspi serial clock (qspi_clk) actively driven clock output from qspi peripheral chip selects (qspi_cs[3:0]) actively driven peripheral selects select the qspi function using the pllcr register. ! ! "#$ %& '"(' ! )* + , - !. % / / / 0123 / !. qspi_cs[0: 3 operation motorola section 16 queued serial peripheral interface (qspi) module 16-3 16.4 operation the qspi uses a dedicated 80-byte block of static ram accessible both to the module and the cpu to perform queued operations. the ram is divided into three segments as follows: 16 command control bytes (command ram) 16 transmit data words (transfer ram) 16 receive data words (transfer ram) ram is organized so that 1 byte of command control data, 1 word of transmit data, and 1 word of receive data comprise 1 queue entry, 0x0?0xf. the user initiates qspi operation by loading a queue of commands in command ram, writing transmit data into transmit ram, and then enabling the qspi data transfer. the qspi executes the queued commands and sets the completion flag in the qspi interrupt register (qir[spif]) to signal their completion. optionally, qir[spife] can be enabled to generate an interrupt. the qspi uses four queue pointers. the user can access three of them through fields in qspi wrap register (qwr): the new queue pointer, qwr[newqp], points to the first command in the queue. an internal queue pointer points to the command currently being executed. the completed queue pointer, qwr[cptqp], points to the last command executed. the end queue pointer, qwr[endqp], points to the final command in the queue. the internal pointer is initialized to the same value as qwr[newqp]. during normal operation, the following sequence repeats: 1. the command pointed to by the internal pointer is executed. 2. the value in the internal pointer is copied into qwr[cptqp]. 3. the internal pointer is incremented. execution continues at the internal pointer address unless the qwr[newqp] value is changed. after each command is executed, qwr[endqp] and qwr[cptqp] are compared. when a match occurs, qir[spif] is set and the qspi stops unless wraparound mode is enabled. setting qwr[wren] enables wraparound mode. qwr[newqp] is cleared at reset. when the qspi is enabled, execution begins at address 0x0 unless another value has been written into qwr[newqp]. qwr[endqp] is cleared at reset but is changed to show the last queue entry before the qspi is enabled. qwr[newqp] and qwr[endqp] can be written at any time. when the qwr[newqp] value changes, the internal pointer value also changes unless a transfer is in progress, in which case the transfer completes normally. leaving qwr[newqp] and qwr[endqp] set to 0x0 causes a single transfer to occur when the qspi is enabled. data is transferred relative to qspi_clk which can be generated in any one of four combinations of phase and polarity using qmr[cpha, cpol]. data is transferred most significant bit (msb) first. the number of bits transferred defaults to eight, but can be set to any value from 8 to 16 by writing a value into the bitse field of the command ram, qcr[bitse]. 16.4.1 qspi ram the qspi contains an 80-byte block of static ram that can be accessed by both the user and the qspi. this ram does not appear in the mcf5249 memory map because it can only be accessed by the user 16-4 mcf5249um motorola operation indirectly through the qspi address register (qar) and the qspi data register (qdr). the ram is divided into three segments with 16 addresses each: receive data ram, the initial destination for all incoming data transmit data ram, a buffer for all out-bound data command ram, where commands are loaded the transmit and command ram are write-only by the user. the receive ram is read-only by the user. figure 16-2 shows the ram configuration. the ram contents are undefined immediately after a reset. the command and data ram in the qspi is indirectly accessible with qdr and qar as 48 separate locations that comprise 16 words of transmit data, 16 words of receive data and 16 bytes of commands. a write to qdr causes data to be written to the ram entry specified by qar[addr] and causes the value in qar to increment. correspondingly, a read at qdr returns the data in the ram at the address specified by qar[addr]. this also causes qar to increment. a read access requires a single wait state. relative address register function 0x00 qtr0 transmit ram 0x01 qtr1 .. 16 bits wide . . . . 0x0f qtr15 0x10 qrr0 receive ram 0x11 qrr1 . . 16 bits wide . . . . 0x1f qrr15 0x20 qcr0 command ram 0x21 qcr1 . . 8 bits wide . . . . 0x2f qcr15 figure 16-2 qspi ram model operation motorola section 16 queued serial peripheral interface (qspi) module 16-5 16.4.1.1 transmit ram data to be transmitted by the qspi is stored in the transmit ram segment located at addresses 0x0 to 0xf. the user normally writes 1 word into this segment for each queue command to be executed. the user cannot read transmit ram. out-bound data must be written to transmit ram in a right-justified format. the unused bits are ignored. the qspi copies the data to its data serializer (shift register) for transmission. the data is transmitted most significant bit first and remains in transmit ram until overwritten by the user. 16.4.1.2 receive ram data received by the qspi is stored in the receive ram segment located at 0x10 to 0x1f in the qspi ram space. the user reads this segment to retrieve data from the qspi. data words with less than 16 bits are stored in the least significant bits of the ram. unused bits in a receive queue entry are set to zero upon completion of the individual queue entry. note: throughout coldfire documentation, ?word? is used consistently and exclusively to designate a 16-bit data unit. the only exceptions to this rule appear in the sections that detail serial communication modules such as the qspi that supports variable-length data units. to simplify this issue, the functional unit is referred to as a ?word? regardless of length. qwr[cptqp] shows which queue entries have been executed. the user can query this field to determine which locations in receive ram contain valid data. 16.4.1.3 command ram the cpu writes one byte of control information to this segment for each qspi command to be executed. command ram is write-only memory from a user?s perspective. command ram consists of 16 bytes with each byte divided into two fields. the peripheral chip select field controls the qspi_cs signal levels for the transfer. the command control field provides transfer options. a maximum of 16 commands can be in the queue. queue execution proceeds from the address in qwr[newqp] through the address in qwr[endqp]. the qspi executes a queue of commands defined by the control bits in each command ram entry which sequence the following actions: chip-select pins are activated data is transmitted from transmit ram and received into the receive ram the synchronous transfer clock qspi_clk is generated before any data transfers begin, control data must be written to the command ram, and any out-bound data must be written to transmit ram. also, the queue pointers must be initialized to the first and last entries in the command queue. data transfer is synchronized with the internally generated qspi_clk, whose phase and polarity are controlled by qmr[cpha] and qmr[cpol]. these control bits determine which qspi_clk edge is used to drive outgoing data and to latch incoming data. 16-6 mcf5249um motorola operation 16.4.2 baud rate selection baud rate is selected by writing a value from 2?255 into qmr[baud]. the qspi uses a prescaler to derive the qspi_clk rate from the system clock, sysclk, divided by two. a baud rate value of zero turns off the qspi_clk. the desired qspi_clk baud rate is related to sysclk and qmr[baud] by the following expression: qmr[baud] = sysclk / [2 (desired qspi_clk baud rate)] 16.4.3 transfer delays the qspi supports programmable delays for the qspi_cs signals before and after a transfer. the time between qspi_cs assertion and the leading qspi_clk edge, and the time between the end of one transfer and the beginning of the next, are both independently programmable. the chip select to clock delay enable (dsck) bit in command ram, qcr[dsck], enables the programmable delay period from qspi_cs assertion until the leading edge of qspi_clk. qdlyr[qcd] determines the period of delay before the leading edge of qspi_clk. the following expression determines the actual delay before the qspi_clk leading edge: qspi_cs-to-qspi_clk delay = qcd/sysclk frequency qcd has a range of 1?127. when qcd or dsck equals zero, the standard delay of one-half the qspi_clk period is used. the delay after transmit enable (dt) bit in command ram enables the programmable delay period from the negation of the qspi_cs signals until the start of the next transfer. the delay after transfer can be used to provide a peripheral deselect interval. a delay can also be inserted between consecutive transfers to allow serial a/d converters to complete conversion. there are two transfer delay options: the user can choose to delay a standard period after serial transfer is complete or can specify a delay period. writing a value to qdlyr[dtl] specifies a delay period. the dt bit in command ram determines whether the standard delay period (dt = 0) or the specified delay period (dt = 1) is used. the following expression is used to calculate the delay: delay after transfer = 32 qdlyr[dtl] /sysclk frequency (dt = 1) where qdlyr[dtl] has a range of 2?255. a zero value for dtl causes a delay-after-transfer value of 8192/sysclk frequency. standard delay after transfer = 17/sysclk frequency (dt = 0) table 16-2 qspi_clk frequency as function of cpu clock and baud rate cpu clock qmr [baud] 66 mhz 48 mhz 33 mhz 20 mhz 2 16,500,000 12,000,000 8,250,000 5,000,000 4 8,250,000 6,000,000 4,125,000 2,500,000 8 4,125,000 3,000,000 2,062,500 1,250,000 16 2,062,500 1,500,000 1,031,250 625,000 32 1,031,250 750,000 515,625 312,500 255 129,412 94,118 64,706 39,216 operation motorola section 16 queued serial peripheral interface (qspi) module 16-7 adequate delay between transfers must be specified for long data streams because the qspi module requires time to load a transmit ram entry for transfer. receiving devices need at least the standard delay between successive transfers. if sysclk is operating at a slower rate, the delay between transfers must be increased proportionately. 16.4.4 transfer length there are two transfer length options. the user can choose a default value of 8 bits or a programmed value of 8 to 16 bits inclusive. the programmed value must be written into qmr[bits]. the bits per transfer enable (bitse) field in the command ram determines whether the default value (bitse = 0) or the bits[3?0] value (bitse = 1) is used. qmr[bits] gives the required number of bits to be transferred, with 0b0000 representing 16. 16.4.5 data transfer operation is initiated by setting qdlyr[spe]. shortly after qdlyr[spe] is set, the qspi executes the command at the command ram address pointed to by qwr[newqp]. data at the pointer address in transmit ram is loaded into the data serializer and transmitted. data that is simultaneously received is stored at the pointer address in receive ram. when the proper number of bits has been transferred, the qspi stores the working queue pointer value in qwr[cptqp], increments the working queue pointer, and loads the next data for transfer from the transmit ram. the command pointed to by the incremented working queue pointer is executed next unless a new value has been written to qwr[newqp]. if a new queue pointer value is written while a transfer is in progress, then that transfer is completed normally. when the cont bit in the command ram is set, the qspi_cs signals are asserted between transfers. when cont is cleared, qspi_cs[3:0] are negated between transfers. the qspi_cs signals are not high impedance. when the qspi reaches the end of the queue, it asserts the spif flag, qir[spif]. if qir[spife] is set, an interrupt request is generated when qir[spif] is asserted. then the qspi clears qdlyr[spe] and stops, unless wraparound mode is enabled. wraparound mode is enabled by setting qwr[wren]. the queue can wrap to pointer address 0x0, or to the address specified by qwr[newqp], depending on the state of qwr[wrto]. in wraparound mode, the qspi cycles through the queue continuously, even while requesting interrupt service. qdlyr[spe] is not cleared when the last command in the queue is executed. new receive data overwrites previously received data in the receive ram. each time the end of the queue is reached, qir[spife] is set. qir[spif] is not automatically reset. if interrupt driven qspi service is used, the service routine must clear qir[spif] to abort the current request. additional interrupt requests during servicing can be prevented by clearing qir[spife]. there are two recommended methods of exiting wraparound mode: clearing qwr[wren] or setting qwr[halt]. exiting wraparound mode by clearing qdlyr[spe] is not recommended because this may abort a serial transfer in progress. the qspi sets spif, clears qdlyr[spe], and stops the first time it reaches the end of the queue after qwr[wren] is cleared. after qwr[halt] is set, the qspi finishes the current transfer, then stops executing commands. after the qspi stops, qdlyr[spe] can be cleared. 16-8 mcf5249um motorola programming model 16.5 programming model the programming model for the qspi consists of six registers. they are the qspi mode register (qmr), qspi delay register (qdlyr), qspi wrap register (qwr), qspi interrupt register (qir), qspi address register (qar), and the qspi data register (qdr). there are a total of 80 bytes of memory used for transmit, receive, and control data. this memory is accessed indirectly using qar and qdr. registers and ram are written and read by the cpu. 16.5.1 qspi mode register (qmr) the qmr register, shown in figure 16-3 , determines the basic operating modes of the qspi module. parameters such as clock polarity and phase, baud rate, master mode operation, and transfer size are determined by this register. the data output high impedance enable, dohie, controls the operation of qspi_dout between data transfers. when dohie is cleared, qspi_dout is actively driven between transfers. when dohie is set, qspi_dout assumes a high impedance state. note: because the qspi does not operate in slave mode, the master mode enable bit, qmr[mstr], must be set for the qspi module to operate correctly. note: all qspi registers must be accessed as 16-bits only. table 16-3 gives qmr field descriptions. 15 14 13 10 9 8 7 0 field mst r dohie bits cpo l cpha baud reset 0000_0001_0000_0100 r/w r/w addres s mbar + 0 x 400 figure 16-3 qspi mode register (qspimr) table 16-3 qspimr field descriptions bits name description 15 mstr master mode enable. 0 reserved, do not use. 1 the qspi is in master mode. must be set for the qspi module to operate correctly. 14 dohie data output high impedance enable. selects qspi_dout mode of operation. 0 default value after reset. qspi_dout is actively driven between transfers. 1 qspi_dout is high impedance between transfers. programming model motorola section 16 queued serial peripheral interface (qspi) module 16-9 figure 16-4 shows an example of a qspi clocking and data transfer. figure 16-4 qspi clocking and data transfer example 13?10 bits transfer size. determines the number of bits to be transferred for each entry in the queue. valuebits per transfer 000016 0001? 0111 reserved 1000 8 1001 9 101010 101111 110012 110113 111014 111115 9 cpol clock polarity. defines the clock polarity of qspi_clk. 0 the inactive state value of qspi_clk is logic level 0. 1 the inactive state value of qspi_clk is logic level 1. 8 cpha clock phase. defines the qspi_clk clock-phase. 0 data captured on the leading edge of qspi_clk and changed on the following edge of qspi_clk. 1 data changed on the leading edge of qspi_clk and captured on the following edge of qspi_clk. 7?0 baud baud rate divider. the baud rate is selected by writing a value in the range 2?255. a value of zero disables the qspi. the desired qspi _clk baud rate is related to sysclk and qmr[baud] by the following expression: qmr[baud] = systemclock / [2 (desired qspi_clk baud rate)] table 16-3 qspimr field descriptions (continued) bits name description qspi_clk qspi_dout qspi_din qspi_cs a b qmr[cpol] = 0 qmr[cpha] = 1 qcr[cont] = 0 chip selects are active low a = qdlyr[qcd] b = qdlyr[dtl] 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 msb 16-10 mcf5249um motorola programming model 16.5.2 qspi delay register (qdlyr) figure 16-5 shows the qspi delay register. note: all qspi registers must be accessed as 16-bits only. table 16-4 gives qdlyr field descriptions. table 16-4 qdlyr field descriptions 16.5.3 qspi wrap register (qwr) note: all qspi registers must be accessed as 16-bits only. 15 14 8 7 0 field spe qcd dtl reset 0000_0100_0000_0100 r/w r/w addres s mbar + 0x404 figure 16-5 qspi delay register (qdlyr) bits name description 15 spe qspi enable. when set, the qspi initiates transfers in master mode by executing commands in the command ram. automatically cleared by the qspi when a transfer completes.the user can also clear this bit to abort transfer unless qir[abrtl] is set. the recommended method for aborting transfers is to set qwr[halt]. 14?8 qcd qspilck delay. when the dsck bit in the command ram, is set this field determines the length of the delay from assertion of the chip selects to valid qspi_clk transition. 7?0 dtl delay after transfer.when the dt bit in the command ram sets this field, it determines the length of delay after the serial transfer. 15 14 13 12 11 8 7 4 3 0 field halt wren wrto csiv endqp ? newqp reset 0000_0000_0000_0000 r/w r/w address mbar + 0 x 408 figure 16-6 qspi wrap register (qwr) programming model motorola section 16 queued serial peripheral interface (qspi) module 16-11 table 16-5 gives qwr field descriptions. 16.5.4 qspi interrupt register (qir) figure 16-7 shows the qspi interrupt register. note: all qspi registers must be accessed as 16-bits only. table 16-6 describes qir fields. table 16-5 qwr field descriptions bits name description 15 halt halt transfers. assertion of this bit causes the qspi to stop execution of commands once it has completed execution of the current command. 14 wren wraparound enable. enables wraparound mode. 0 execution stops after executing the command pointed to by qwr[endqp]. 1 after executing command pointed to by qwr[endqp], wrap back to entry zero, or the entry pointed to by qwr[newqp] and continue execution. 13 wrto wraparound location. determines where the qspi wraps to in wraparound mode. 0 wrap to ram entry zero. 1 wrap to ram entry pointed to by qwr[newqp]. 12 csiv qspi_cs inactive level. 0 qspi chip select outputs return to zero when not driven from the value in the current command ram entry during a transfer (that is, inactive state is 0, chip selects are active high). 1 qspi chip select outputs return to one when not driven from the value in the current command ram entry during a transfer (that is, inactive state is 1, chip selects are active low). 11?8 endqp end of queue pointer. points to the ram entry that contains the last transfer description in the queue. 7?4 cptqp completed queue entry pointer. points to the ram entry that contains the last command to have been completed. this field is read only. 3?0 newqp start of queue pointer. this 4-bit field points to the first entry in the ram to be executed on initiating a transfer. 15 14 13 12 11 10 9 8 7 4 3 2 1 0 field wcefb abrtb ? abrtl wcefe abrte ? spife ? wcef abrt ? spif reset 0000_0000_0000_0000 r/w r/w addres s mbar + 0 x 40c figure 16-7 qspi interrupt register (qir) 16-12 mcf5249um motorola programming model the command and data ram in the qspi is indirectly accessible with qdr and qar as 48 separate locations that comprise 16 words of transmit data, 16 words of receive data and 16 bytes of commands. a write to qdr causes data to be written to the ram entry specified by qar[addr]. this also causes the value in qar to increment. correspondingly, a read at qdr returns the data in the ram at the address specified by qar[addr]. this also causes qar to increment. a read access requires a single wait state. note: the qar does not wrap after the last queue entry within each section of the ram. 16.5.5 qspi address register (qar) the qar, shown in figure 16-8 , is used to specify the location in the qspi ram that read and write operations affect. table 16-6 qir field descriptions bits name description 15 wcefb write collision access error enable. a write collision occurs during a data transfer when the ram entry containing the command currently being executed is written to by the cpu with the qdr. when this bit is asserted, the write access to qdr results in an access error. 14 abrtb abort access error enable. an abort occurs when qdlyr[spe] is cleared during a transfer. when set, an attempt to clear qdlyr[spe] during a transfer results in an access error. 13 ? reserved, should be cleared. 12 abrtl abort lock-out. when set, qdlyr[spe] cannot be cleared by writing to the qdlyr. qdlyr[spe] is only cleared by the qspi when a transfer completes. 11 wcefe write collision interrupt enable. interrupt enable for wcef. setting this bit enables the interrupt, and clearing it disables the interrupt. 10 abrte abort interrupt enable. interrupt enable for abrt flag. setting this bit enables the interrupt, and clearing it disables the interrupt. 9 ? reserved, should be cleared. 8 spife qspi finished interrupt enable. interrupt enable for spif. setting this bit enables the interrupt, and clearing it disables the interrupt. 7?4 ? reserved, should be cleared. 3 wcef write collision error flag. indicates that an attempt has been made to write to the ram entry that is currently being executed. writing a 1 to this bit clears it and writing 0 has no effect. 2 abrt abort flag. indicates that qdlyr[spe] has been cleared by the user writing to the qdlyr rather than by completion of the command queue by the qspi. writing a 1 to this bit clears it and writing 0 has no effect. 1 ? reserved, should be cleared. 0 spif qspi finished flag. asserted when the qspi has completed all the commands in the queue. set on completion of the command pointed to by qwr[endqp], and on completion of the current command after assertion of qwr[halt]. in wraparound mode, this bit is set every time the command pointed to by qwr[endqp] is completed. writing a 1 to this bit clears it and writing 0 has no effect. programming model motorola section 16 queued serial peripheral interface (qspi) module 16-13 note: all qspi registers must be accessed as 16-bits only. 16.5.6 qspi data register (qdr) the qdr, shown in figure 16-9 , is used to access qspi ram indirectly. the cpu reads and writes all data from and to the qspi ram through this register. note: all qspi registers must be accessed as 16-bits only. 16.5.7 command ram registers (qcr0?qcr15) the command ram is accessed using the upper byte of qdr. the qspi cannot modify information in command ram. there are 16 bytes in the command ram. each byte is divided into two fields. the chip select field enables external peripherals for transfer. the command field provides transfer operations. note: the command ram is accessed only using the most significant byte of qdr and indirect addressing based on qar[addr]. figure 16-10 shows the command ram register. 15 65 0 field ? addr reset 0000_0000_0000_0000 r/w r/w addres s mbar + 0 x 410 figure 16-8 qspi address register (qar) 15 0 field data reset 0000_0000_0000_0000 r/w r/w addres s mbar + 0 x 414 figure 16-9 qspi data register (qdr) 16-14 mcf5249um motorola programming model 15 14 13 12 11 8 7 0 field cont bitse dt dsck qspi_cs ? reset undefined r/w write only addres s qar[addr] figure 16-10 command ram registers (qcr0?qcr15) note: all qspi registers must be accessed as 16-bits only. table 16-7 gives qcr field descriptions. table 16-7 qcr0?qcr15 field descriptions bits name description 15 cont continuous. 0 chip selects return to inactive level defined by qwr[csiv] when transfer is complete. 1 chip selects remain asserted after the transfer of 16 words of data 1 . 14 bitse bits per transfer enable. 0 eight bits 1 number of bits set in qmr[bits] 13 dt delay after transfer enable. 0 default reset value. 1 the qspi provides a variable delay at the end of serial transfer to facilitate interfacing with peripherals that have a latency requirement. the delay between transfers is determined by qdlyr[dtl]. 12 dsck chip select to qspi_clk delay enable. 0 chip select valid to qspi_clk transition is one-half qspi_clk period. 1 qdlyr[qcd] specifies the delay fr om qspi_cs valid to qspi_clk. 11?8 qspi_cs peripheral chip selects. used to select an external device for serial data transfer. more than one chip select may be active at once, and more than one device can be connected to each chip select. 7?0 ? reserved, should be cleared. note: 1. in oreder to keep the chip selects asserted for all transfers, the qwr [csiv] bit must be set to control the level that the chip selects return to after the first transfer. programming model motorola section 16 queued serial peripheral interface (qspi) module 16-15 figure 16-11 qspi timing 16.5.8 programming example the following steps are necessary to set up the qspi 12-bit data transfers and a qspi_clk of 4.125 mhz. the qspi ram is set up for a queue of 16 transfers. all four qspi_cs signals are used in this example. 1. enable qspi_clk and qspi_din pin functionality by setting the qspisel bit in the pllcr register. 2. write the qmr with 0xb308 to set up 12-bit data words with the data shifted on the falling clock edge, and a clock frequency of 4.125 mhz (assuming a 66-mhz sysclk). 3. write qdlyr with the desired delays. 4. write qir with 0xd00f to enable write collision, abort bus errors, and clear any interrupts. 5. write qar with 0x0020 to select the first command ram entry. 6. write qdr with 0x7e00, 0x7e00, 0x7e00, 0x7e00, 0x7d00, 0x7d00, 0x7d00, 0x7d00, 0x7b00, 0x7b00, 0x7b00, 0x7b00, 0x7700, 0x7700, 0x7700, and 0x7700 to set up four transfers for each chip select. the chip selects are active low in this example. 7. write qar with 0x0000 to select the first transmit ram entry. 8. write qdr with sixteen 12-bit words of data. 9. write qwr with 0x0f00 to set up a queue beginning at entry 0 and ending at entry 15. qspics[3:0] qspi_clk qspi_dout qspi_din qs1 qs1: qspics to qspi_clk qs2: qspi_clk to qspi_dout valid qs3: qspi_clk to qspi_dout hold qs4: qspi_din to qspi_clk setup qs2 qs3 qs4 qs5 qs5: qspi_din to qspi_clk hold 1t 1 0 ns 10 ns 10 ns min max 20 ns 1 t1 is defined as the clock period in ns. 16-16 mcf5249um motorola programming model 10.set qdlyr[spe] to enable the transfers. 11.wait until the transfers are complete. qir[spif] is set when the transfers are complete. 12.write qar with 0x0010 to select the first receive ram entry. 13.read qdr to get the received data for each transfer. 14.repeat steps 5 through 13 to do another transfer. motorola section 17 audio functions 17-1 section 17 audio functions 17.1 audio interface overview the audio interface module allows the mcf5249 to receive and transmit digital audio over serial audio interfaces (iis/eiaj) and over digital audio interfaces (iec958). the mcf5249 is equipped with four serial audio interfaces compliant with philips iis and sony eiaj format. the mcf5249 has two iec958 receivers with 4 multiplexed inputs, and one iec958 transmitter with two outputs: one for the professional c-channel and one for the consumer c-channel. the audio interfaces block allows the direct retransmission of an audio signal received on one receiver to another transmitter, without cpu intervention, or it allows the cpu to receive or transmit digital audio to/from any of the audio interfaces. the iec958 receivers and transmitter support main audio. also, the mcf5249 features allow the handling of iec958 c and u channels. a frequency measurement block exists to allow precise measurement of an incoming sampling frequency. 17-2 mcf5249um motorola 17.1.1 audio interface structure figure 17-1 audio interface block diagram iis 1 clock gen iis1 receive iis1 control sclk1 lrck1 sdatai1 iis1 transmit sdatao1 iis1rcvdata(39:0) iis2 clock gen iis2 control iis2 transmit iis4 clock gen iis4 receive iis4 control sdatao2 sclk2 lrck2 sclk4 lrck4 sdatai4 ebuin1 ebuin2 ebuin3 ebuin4 ebu receive block 32-bit ebu "c" channel eburcvuchannelstream ebuextractedclock eburcvdata1 source select iis1 tx fifo iis1 tx source select iis2 tx fifo iis2 tx source select ebu tx block ebu clock gen ebuout2 ebuout1 ebu tx fifo ebu tx source select 32-bit ebu "c" channel clock select ebutxuchannelstream 6 fields 6 fields 6 fields 1 2 3 4 5 6 8 9 10 11 12 13 14 15 18 19 22 23 24 25 26 27 28 29 30 31 iis4rcvdata(39:0) iis3 clock gen iis3 receive iis3 control sclk3 lrck3 sdatai3 6 7 8 iis3rcvdata(39:0) pdir2 fifo pdir2 register (read-only) 6 fields 16 17 block decoder 100 101 block encoder pdor3e pdor3 register (write-only) pdir1 fifo pdir1 register (read-only) 6 fields 16a 17a 0 0 pdir2 source select memory-mapped coldfire process o bus pdor1 register (write only) pdor2 register (write only) reg reg pdor1 pdor2 0 0 bypass select 0 31a ebuoff ( to fre q meas block ) (read only) (read only) (write only) (write only) internal audio data bus ebu receive block eburcvdata2 18a pdir1 fifo pdir3 register (read-only) 6 fields 16b 17b 0 ebuout2 ebuout1 sdatao2 sclk2 lrck2 sdatao1 sclk1 lrck1 sdatai1 sclk3 lrck3 sdati3 sclk4 lrck4 sdatai4 ebuout2 ebuout1 motorola section 17 audio functions 17-3 there are four serial audio interface blocks labeled as follows: 1. iis1: capable of transmitting and receiving audio data. 2. iis2: transmit only. 3. iis3: receive only. 4. iis4: receive only. as shown in figure 17-1 , there two iec958 receivers. the source selector ( 18) and the receiver block itself ( 19) . the receiver is capable of taking its input signal from four possible ebu inputs: 1. ebuin1 2. ebuin2 3. ebuin3 4. ebuin4 there is one iec958 transmitter ( 30 ) with two outputs. one carries the ?professional? c-channel, and the other carries the ?consumer? c-channel. five audio interface receivers (iis1, iis3, iis4, and two ebu receivers) send their received data on an internal 40-bit wide bus, the internal audio data bus. every transmitter sources its data to be transmitted from this same internal bus. every transmitter has a multiplexer to select the data source. possible sources are (iis1 receiver, iis3 receiver, iis4 receiver, two ebu receivers, processor data output1, processor data output2, processor data output 3). every transmitter also has a fifo after the multiplexer. this fifo gives the data source some freedom when data is generated. the fifos compensate for phase shifts when a transmitter takes data from another receiver. in the case that the transmitter sends out processor-generated data, the fifo allows the processor to send several audio words in one burst to the audio transmitter. to allow the mcf5249 processor to receive and transmit audio data, an interface is present between the internal audio data bus and the coldfire memory space. as shown in figure 17-1 , this interface is seen in the mcf5249 memory map as processor data interface registers. three of these are processor data out registers, pdor1, pdor2 and pdor3. when the processor writes to one of these registers, the data is sent directly to the internal audio data bus, and depending on the setting of the multiplexers ( 13, 15, and 24) it will end up in one or several of the transmit fifos (12, 14, and 25) . there are three processor data in registers, pdir1, pdir2, and pdir3. when the processor reads from one of these address locations, it actually reads data from one of the fifos ( 17 , 17a or 17b) . these fifos receive data from the internal audio data bus using multiplexers (16 , 16a and 16b) . depending on the setting of the multiplexers, data from one of the audio data receivers will end in the fifos. possible receivers for the three pdir channels are iis1 receiver, iis3 receiver, iis4 receiver and the two iec958 receivers. besides the mechanism to let the mcf5249 processor access the audio data, there are several interrupts and control registers to allow the mcf5249 to determine when it should read or write data to the appropriate processor data interface register. the iec958 receiver and transmitter handle the main data audio stream in the same way as the iis receivers and transmitters. this is done using the internal audio data bus. additionally, they support the iec958 ?c? and ?u? channels. iec958 ?c? and ?u? channel data is interfaced directly to memory-mapped registers ( 22,26,27 and 28) . 17.1.1.1 audio interrupt mask and interrupt status registers the interrupts of the audio interface feed into vectors 0-31 of the interrupt controller. there are two sets of registers associated with interrupt operation. 17-4 mcf5249um motorola every pending audio interrupt will show up as a ?1? in register interruptstat or interruptstat3. the interrupt will cause the associated interrupt to go active if the corresponding bit in interrupten is set to ?1?. most interrupts are cleared by writing a ?1? to the corresponding bit in interruptclear register. table 17-1 interrupt register addresses address mbar2+ name width description reset value acces s 0x94:0x97 interrupten 32 interrupt enable register 0 rw 0x98:0x9b interruptstat 32 interrupt status register - r 0x98:0x9b interruptclear 32 interrupt clear register - w 0xe4:0xe7 interrupten3 32 interrupt enable register rw 0xe0:0xe3 interruptstat3 32 interrupt status register - r 0xe0:0xe3 interruptclear3 32 interrupt clear register - w table 17-2 interrupt register description bit interrupt name description vector how to clear 31 iis1txunov iis1 transmit fifo under / over 31 reg. intclear 30 iis1txresyn iis1 transmit fifo resync 30 reg. intclear 29 iis2txunov iis2 transmit fifo under / over 29 reg. intclear 28 iis2txresyn iis2 transmit fifo resync 28 reg. intclear 27 ebutxunov iec958 transmit fifo under / over 27 reg. intclear 26 ebutxresyn iec958 transmit fifo resync 26 reg. intclear 25 ebu1cnew iec958-1 receiver new c channel received 25 reg. intclear 24 ebu1valnogood iec958-1 receiver validity bit not set 24 reg. intclear 23 ebu1symerr iec958-1 receiver symbol error 23 reg. intclear 22 ebu1biterr iec958-1 receiver parity bit error 23 reg. intclear 21 uchantxempty u channel transmit register is empty 21 write to tx reg 20 uchantxunder u channel transmit register underrun 20 reg. intclear 19 uchantx nextfirst u channel transmit register next byte will be first 19 write to tx reg 18 u1chanrcvfull u1channelreceive register full 18 read rcv reg 17 u1chanrcvover u1channelreceive register overrun 23 reg. intclear 16 q1chanrcvfull q1channelreceive register full 18 read rcv reg 15 q1chanrcvover q1channelreceive register overrun 13 reg. intclear 14 uq1chansync u/q channel sync found 18 reg. intclear 13 uq1chanerr u/q channel framing error 13 reg intclear 12 pdir1unov processor data in 1 under / over 12 reg intclear serial audio interface (iis/eiaj) motorola section 17 audio functions 17-5 17.2 serial audio interface (iis/eiaj) there are a total of four serial audio interfaces. each interface can handle philips iis or sony eiaj protocol. interface 1 is a receive/transmit interface. interface 2 is transmit only, interfaces 3 and 4 are receive only. see table 17-4 . interface 1 has four pins connected, the others have three pins. every serial audio interface block has a 32-bit configuration register associated with it. 11 pdir1resyn processor data in 1 resync 11 reg intclear 10 pdir2unov processor data in 2 under / over 10 reg intclear 9 pdir2resyn processor data in 2 resync 9 reg intclear 8 audiotick ?tick? interrupt 8 reg intclear 7 u2chanrcvover q2chanoverrun uq2chanerr iec 958 receiver 2 u/q channel error 7 reg intclear 6 pdir3 resync processor data in 3 resync 6 reg intclear 5 pdir3 full processor data in 3 full 5 read frompdir3 4 iis1txempty iis1 transmit fifo empty 4 write to fifo 3 iis2txempty iis2 transmit fifo empty 3 write to fifo 2 ebutxempty ebu transmit fifo empty 2 write to fifo 1 pdir2 full processor data in 2 full 1 read from pdir2 0 pdir1 full processor data in 1 full 0 read from pdir1 table 17-3 interrupten3 interruptclear3, interruptstat3 register description bit interrupt name description vector how to clear 25 ebu2cnew iec958-2 receiver new c channel received 17 reg. intclear3 24 ebu2valnogood iec958-2 receiver validity bit not set 16 reg. intclear3 23 ebu2symerr iec958-2 receiver symbol error 15 reg. intclear3 22 ebu2biterr iec958-2 receiver pa rity bit error 15 reg. intclear3 18 uchanrcvfull u2channelreceive register full 14 read rcv reg 17 uchanrcvover u2channelreceive register overrun 7 reg. intclear3 16 qchanrvfull q2channelreceive register full 14 read rcv reg 15 qchanoverrun q2channelreceive register overrun 7 reg. intclear3 14 uqchansync u/q2 channel sync found 14 reg. intclear3 13 uqchanerr u/q2 channel framing error 7 reg intclear3 table 17-2 interrupt register description bit interrupt name description vector how to clear 17-6 mcf5249um motorola serial audio interface (iis/eiaj) note: each of the four iis interfaces is capable of operating in philips iis mode or sony eiaj mode with either 32, 36, or 40 bits per word clock. timing diagrams describing each of these modes are given in the following sections. the frequency of the clock and data signals is programmable, as is the inversion of the bit clock (sclk) or word clock (lrck) for each iis interface. inversion of the lrck clock only operates correctly on a slave receiver, therefore iis3 iis4. if iis1 is being used for transmit and receive in master mode then lrck will be inverted on both the input and the output. thereby cancelling the effect. the sclk and lrck signals for each iis interface can be inputs to the interface or they can be generated internally. see table 17-7 . . table 17-4 iis1 configuration registers (0x10) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field ef/cflg insert cflg sample position txsource select reset 0000 0 0 0 000 0 0 0 0 0 r/w r/w bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field clocksel tx fifo control txsource select size mode lrck frequency lrck invert sclk invert reset 0000 1 1 1 111 0 1 0 0 0 r/w r/w addr (iis1config) mbar2 + 0x10 (reset 0x0fc8) table 17-5 iis2 configuration registers (0x14) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field txsource select reset 0000 0 0 0 000 0 1 0 0 0 r/w r/w bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field clocksel tx fifo control txsource select size mode lrck frequency lrck invert sclk invert reset 0000 1 1 1 111 0 1 0 0 0 r/w r/w addr (iis2config) mbar2 + 0x14 (reset 0x0fc8) table 17-6 iis3,4 configuration registers (0x18, 0x1c) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field reset 0000 1 0 0 000 0 0 0 0 0 r/w r/w serial audio interface (iis/eiaj) motorola section 17 audio functions 17-7 bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field clocksel size mode lrck frequency lrck invert sclk invert reset 0 0 0 0 1 1 1 1 1 1 0 1 0 0 0 r/w r/w addr (iis3config) mbar2 + 0x18 (reset 0x0fc8) (iis4config) mbar2 + 0x1c (reset 0x0fc8) table 17-7 iis configuration bit descriptions bit name bits description ef/cflg insert 18 see note 16 0: not active 1: active cflg sample position 17 see note 16 0: sample cflg input 1 sclk clock after incoming lrck edge 1: sample cflg input 6 sclk clocks before incoming lrck edge clocksel 15,14,13, 12 see notes 1, 11, and 14 following bit these descriptions. 0000: sclk/lrck is input 0001: sclk: audio clk/ 24 0010: sclk: audio clk / 16 0011: sclk: audio clk / 12 0100: sclk: audio clk / 8 0101: sclk: audio clk / 6 0110: sclk: audio clk / 4 0111: sclk: audio clk / 3 1100: sclk: audio clk / 2 1000: sclk, lrck: follow iis1 1001: sclk, lrck: follow iis2 1010: sclk, lrck: follow iis3 1011: sclk, lrck: follow iis4 tx fifo control 11 see notes 2, 7, 13, and 15 following these bit descriptions. 1: reset to 1 sample remaining 0: normal operation txsource select 16,10,9,8 see notes 2, 9, 12, and 15 following bit these descriptions. bits 16, 10-8 0 000: digital zero 0 001: pdor1 0 010: pdor2 0 011: pdor3 0 100: iis1 rcvdata 0 101: iis3 rcvdata 0 110: iis4 rcvdata 0 111: ebu rcvdata 1 000: ebu2 rcvdata table 17-6 iis3,4 configuration registers (0x18, 0x1c) 17-8 mcf5249um motorola serial audio interface (iis/eiaj) size 7,6 see notes 3, 4, and 8 following bit these descriptions. 00: 16 bits 01: 18 bits 10: 20 bits 11: zero mode 5 1 = sony, eiaj mode 0 = philips iis mode lrck frequency 4,.3,2 100: 64 bit clocks / word clock 010: 48 bit clocks / word clock 000: 32 bit clocks / word clock other settings: reserved, undefined lrck invert 1 see note 5 following bit these descriptions. 1 = invert on word clock 0 = no invert on word clock sclk invert 0 see note 6following bit these descriptions. 1 = invert on bit clock 0 = no invert on bit clock note: 1. audio clk is normally 16.93 mhz. actual value given table 4-4 on page 5 . when divided sysclock is selected as sclk output, lrck will be output too, and is divided from sclk, using division factor defined by field 4,3,2 - lrck frequency . note: 2. when bit 11 is set, fifo is in reset condition. the fifo is always re-set to ?1 sample remaining?. the value of the rem aining one sample will be all-zero. note: 3. when philips iis mode is selected, 16-18-20 bits should yield same result. note: 4. internal interface in mcf5249 is 40 bits / sample (20 left + 20 right). 16, 18 bit words are padded with zeros note: 5. lrck invert will invert the incoming lrck signal between the pin and the serial data receiver and transmitter note: 6. sclk invert will invert the incoming sclk signal between the pin and the serial data receiver and transmitter. note: 7. reset to one sample remaining is us ed to synchronize the data transfer from one input interface to another output inter face running at the same frequency. note: 8. ?zero? means data is transferred at the samplin g frequency, with all data cleared down to digital zero. note: 9. pdor1, pdor2, pdor3: coldfire data out registers. note: 10. serial data transmit / receive interfaces have no limit on minimum incoming or outgoing sampling frequency. the maximu m sclk frequency is limited to 1/3 of the internal system clock (cpuclk/2). mark/space ratio should be equal or better than 38/62. note: 11. reprogramming bits 15-12 during functional operation is not allowed. reprogramming only allowed while fifo is in reset condition (bit 11 set ?1?) note: 12. when ?digital zero? is selected as source, the fifo outputs ?zero? on its outgoing data bus, regardless of the input s ide and content of the fifo. no fifo related exceptions are generated. note: 13. when the fifo leaves the reset state, because the user writes a ?normal operation? state into the control register, wh ile previous state was reset state, the fifo is kept in reset until the first long-word is written to it. as a result, the ?start? of the normal operation is synchronized with the writing of the first data into the fifo. note: 14. when iis/sony interface lrck/sclk is set in ?follow iis? mode, the bit clock and word clock become exactly identical t o bit and word clock of followed interface. if e.g. lrck/sclk for iis interface 2 is set in ?follow iis1?, the dac or ad connected to iis2 can use bit clock and word clock of iis1. bit and word clock for iis2 can be used as gpio. note: 15. bit 16 extends the tx fifo control bit and the bit order becomes 16, 10, 9, 8. note: 16. these bits should be programmed zero for normal operation. for interface1 receiver, it is possible to use the special ef/cflg insertion mode, by setting bit 18 = 1. this mode is intended to interface with philips cd decoders (saa7345 and successors). when this mode is used, iis1config must be programmed to ?sony? mode, 16 bits. the saa7345 must also be programmed to ?sony? mode, 16 bits. the cflg flag coming from saa7345 must be connected with cflg input. the ef flag coming from saa7345 must be connected with ef input. if all this is done correctly, the device will receive the 16 msb ?s of the incoming data in bits [17:2] of the received se rial data. bit [1] of the received data is the ef flag of the corresponding word, as output by saa7345. bit [1] will be set if the msb or the lsb or both are flagged. bit [0] of the received data is the cflg flag of the corresponding word, as output by saa7345. these flags can be used for implementing an electronic shock protection fifo. table 17-7 iis configuration bit descriptions bit name bits description serial audio interface (iis/eiaj) motorola section 17 audio functions 17-9 17.2.1 iis/eiaj transmitter descriptions the two iis/eiaj transmitters operate independently. each of the transmitters has the capability of transmitting data from one of several sources: one of the three processor data out registers. one of the three iis receivers. the digital audio (ebu) receiver. digital zero. the source of the transmit data is programmable. 17.2.2 iis/eiaj transmitter interrupts there are a number of exceptions defined within the serial audio interface transmitters: serial audio interface1 transmit fifo overrun or underrun serial audio interface1 transmit fifo left/right resynchronization serial audio interface1 transmit fifo empty serial audio interface 2 transmit fifo overrun or underrun serial audio interface 2 transmit fifo left/right resynchronization serial audio interface 2 transmit fifo empty the action of the iis transmitters on fifo underrun is to repeat the last sample. timing diagrams for iis/eiaj mode are shown in figure 17-2 and figure 17-3 . data out and word clock out is clocked on the falling edge of the sclk bit clock (noninverted). 17.2.3 iis/eiaj receiver descriptions each of the three iis receivers operates independently. for timing diagrams, see figure 17-2 and figure 17-3 . the data can be clocked into each receiver using an external sclk/lrck or using an internally-generated sclk/lrck. data is always clocked on the rising edge of the sclk bit clock (noninverted). figure 17-2 iis/eiaj timing diagram (16 sclk edges per word) sclk (inverted clock) sclk (noninverted) lrck(iis) left (if noninverted) data out data in d19 d18 d17 d15 d13 d11 d9 d7 d5 d19 d17 d4 d16 d14 d12 d10 d8 d6 d4 d18 lrck(sony-16 bit) left (if noninverted) 17-10 mcf5249um motorola digital audio interface (ebu) figure 17-3 iis/eiaj timing diagram (24 or 32 sclk edges per word) note: in 18-bit mode, bits d1 and d0 are set 0. in 16-bit mode, bits d3,d2,d1 and d0 are set 0. 17.3 digital audio interface (ebu) table 17-8 ebu1config register bits 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field tx source select clocksel tx fifo control tx source select iec958 receive source select val control iec958 out select u source select reset 0 0 1 1 1 1 1 1 0 0 0 0 0 0 0 0 r/w r/w addr mbar2 + 0x20:0x23 (reset 0x3f00) sclk (inverted clock) sclk (noninverted) lrck(iis) left (if noninverted) data out data in d19 d18 d17 d15 d13 d11 d9 d7 d5 d3 d1 d16 d14 d12 d10 d8 d6 d4 d2 lrck(sony-16 bit) left (if noninverted) d0 lrck(sony-20 bit) lrck(sony-18 bit) digital audio interface (ebu) motorola section 17 audio functions 17-11 table 17-9 ebu1config register bit descriptions field - bits name description reset notes 15,14,13,12 clocksel 0000: iec958 clock: audioclk / 16 0001: iec958 clock: audioclk / 12 0010: iec958 clock: audioclk / 8 0011: iec958 clock: audioclk / 6 0100: iec958 clock: audioclk / 4 0101: iec958 clock: audioclk / 3 0110: iec958 clock: sclk1 0111: iec958 clock: sclk2 1000: iec958 clock: sclk3 1001: iec958 clock: sclk4 0011 1,2,8 11 tx fifo control 1: reset to one sample remaining 0: normal operation 1111 3,5, 11 16,10,9,8 txsource select 0 000: digital zero 0 001: pdor1 0 010: pdor2 0 011: pdor3 0 100: iis1rcvdata 0 101: iis3rcvdata 0 110: iis4rcvdata 0 111: ebu1rcvdata 1 000: ebu2rcvdata 1111 3,6,9 7,6 iec958 receive source select 00: ebu in 1 01: ebu in 2 10: ebu in 3 11: ebu in 4 00 5 valcontrol 0: outgoing ?v? flag always 1 1: outgoing ?v? flag always 0 010 4,3,2 iec958 out select 000: off. output ?0? 001: feed-through ebuin1 010: feed-through ebuin2 011: feed-through ebuin3 100: feed-through ebuin4 101: normal operation 000 12 17-12 mcf5249um motorola digital audio interface (ebu) 1,0 u source select 00: no embedded u channel 01: u channel from iec958 receive block. (cd mode) 10: reserved, undefined 11: u channel from on-chip u channel transmitter. 00 4 1. iec958 interface needs 64 * audio sample frequency clock for good operation. this is 2.822 mhz for operation at 44.1 khz sampling frequency. 2. when iec958 is set to follow sclk1, sclk2, sclk3 or sclk4, iec958 will transmit at same rate as serial audio interface only if the interface uses 64 bit clocks / word clock format. 3.when bit 11 is set, fifo is in reset condition. the fifo is always re-set to ?contains 1 sample?. this sample value is re-set at the same time to ?all-zero?. 4. u channel selection is described on section handling subcode processing. 5. application info. before starting iec958 transmission to copy data from another incoming channel, first reset the fifo to one sample remaining, while source selector is set to correct source. when fifo is switched to normal operation, transmission will start normally. 6. digital zero means data transmitted is digital zero, while ?c? and ?u? channel contain valid data. when digital zero is transmitted, iec958 transmit fifo is not read any more by iec958 transmit hardware. 7. pdor1, pdor2, pdor3: coldfire data out register. 8. reprogramming bits 15-12 during functional operat ion is not allowed. reprogramming only allowed while fifo is in reset condition (bit 11 set ?1?) 9. when ?digital zero? is selected as source, the fifo outputs ?zero? on its outgoing data bus, regardless of the input side and content of the fifo. no fifo related exceptions are generated. 10. this bit controls the outgoing validity flag of the ebu transmitter. when it is re-set, all outgoing data is flagged as ?valid?. if it is set, all data is flagged ?invalid?. 11. when the fifo leaves the reset state, because t he user write a ?normal operation? state into the control register, while previous state was reset state, the fifo is kept into reset until first long-word is written to it. as a result, the ?start? of the normal operation is synchronized with the writing of the first data into the fifo. 12. this field selects what is output on ebuout1. if field is ?000,? the spdif output is off, outputs 0. if field is ?001? to ?100,? it muxes out one of the ebuin?s to the ebuout, without any reformatting. when the field is set to ?101,? this is normal operation of the spdif transmitter. table 17-10 ebu2config register bits 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field iec958 receive source select reset 0 0 1 1 1 1 1 1 0 0 00 0 0 0 0 0 r/w r/w addr mbar2 + 0xd0: 0xd3 (reset 0x3f00) table 17-11 ebu2config register bit descriptions field - bits name description reset notes 7,6 iec958 receive source select 00: ebu in 1 01: ebu in 2 10: ebu in 3 11: ebu in 4 00 table 17-9 ebu1config register bit descriptions field - bits name description reset notes digital audio interface (ebu) motorola section 17 audio functions 17-13 17.3.1 iec958 receive interface the iec958 receive interface consists of 2 blocks: 1. the source selector 2. the iec958 receiver itself the source is selected by programming the appropriate ebu control register bits 7:6. the receiver then extracts the data from the stream and outputs the data on the internal audio bus. the data can then be used by the processor (using the pdir and other registers) or by the iis or ebu transmit interface. in the case of the data being used as input to one of the iis transmitters, the data rate of the incoming ebu data must match exactly with that of the iis transmitter. the following functions are performed by the block. 17.3.1.1 audio data reception the iec958 receive block (19) extracts the audio data from the stream and puts this in 20-bit format on internal audio data bus. the format is exactly the same as the format produced by the serial data interfaces. 17.3.1.2 control channel reception for a description of the control (or ?c?) channel in ebu data formatting, refer to iec958-3 description of control channel. there are two 32-bit registers, one for each receiver, which receive the first 32 bits of the ?c? channel. no interpretation is done. see table 17-12 bits are ordered first bit left. so, c-channel bit ?0? is seen in bit position 31 in the eburcvcchannel register. c-channel bit ?31? is seen as the lsb bit in the register. 17.3.1.3 control channel interrupt (iec958 ?c? channel new frame) when the value of a new iec958 ?c? channel frame is loaded into the eburcvcchannel register, an interrupt is generated. this interrupt is cleared when the processor writes the corresponding bit in the interruptclear register. eburcvcchannel is double buffered. meaningful values can be read at any time. 17.3.1.4 validity flag reception an interrupt is associated with the validity flag. (interrupt 24 - iec958valnogood). this interrupt is set every time a frame is seen on the iec958 interface with the validity bit set to ?invalid?. table 17-12 eburcvcchannel register bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field eburcvc channel1 and channel2 reset ---------------- r/w read only bits1514131211109876543210 field eburcvc channel1 and channel2 reset ---------------- r/w read only addr ebu1rcvcchannel mbar2 + 0x24: ebu2rcvcchannel mbar2 + 0xd4: 17-14 mcf5249um motorola digital audio interface (ebu) 17.3.1.5 iec958 exception definition there are several iec958 exceptions defined that will trigger an interrupt. these are: control channel change ? set when eburcvcchannel register is updated. the register is updated for every new c-channel received. the exception is reset when eburcvcchannel register is read. ebu illegal symbol ? set on reception of illegal symbol during iec958 receive. reset by writing register interruptclear. refer to the section on interrupts for details. the ebu input is a biphase/mark modulated signal. the time between any two successive transitions of the ebu signal is always 1, 2 or 3 ebu symbol periods long. the ebu receiver will parse the stream, and split it in so-called symbols. it recognizes s1, s2 and s3 symbols, depending on the length of the symbols. not all sequences of these symbols are allowed. to give an example, a sequence s2-s1-s1-s1-s2 cannot occur in a error-free ebu signal. if the receiver finds such an illegal sequence, the illegal symbol interrupt is set. no corrective action is undertaken. when the interrupt occurs, this means that (a) the ebu signal is destroyed by noise (b) the ebu frequency changed. iec958 bit error ? set on reception of bit error. (parity bit does not match). reset on write to interruptclear register. refer to the section on interrupts for details. 17.3.1.6 ebu extracted clock the clock from the ebu signal is extracted for measurement purposes only. it cannot be used as a clock to drive other audio interfaces like iis. the average rate is 128 x the sampling frequency (ex. 128 * 44.1 khz for 44.1 khz input sampling frequency). the internal signal is used in the freqmeas circuit to generate the frequency measurement. 17.3.1.7 reception of user channel and cd-subcode over iec958 receiver the iec958 receiver is capable of extracting the user channel bits out of the data stream. the extracted bits are assembled in the 32-bit ? uchannelreceive? register, with the first u-channel bit in the msb position (bit 31). the interface can be configured to detect sync patterns in the u-channel in the case the u-channel contains cd subcode (cd-mode). the sync detection can be enabled by setting the usyncmode bits in the cd-subcode register ( table 17-15 ). sync recognition is done as follows: ? internally, a symbol starting with a ?1? is treated as a ?data symbol?. any consecutive 11 zeros are treated as a ?zero symbol? ? the sync detector will assume user channel sync whenever: (a) a sequence of 4 symbols, data-sync-sync-data, is found. (b) 98 symbols (does not matter data or zero) after the previous ?sync symbols? ? the channellengtherror interrupt is set when a new sync is not found at the correct distance from the previous sync, or if uchannelreceive or qchannelreceive do not contain the correct number of bits/bytes. furthermore, in cd-mode, the q-channel receiver extracts the q-channel cd-subcode from the u-channel stream and assembles the bits in the 32-bit ? qchannelreceive? with the first bit in the msb position. associated registers are shown in the following table: digital audio interface (ebu) motorola section 17 audio functions 17-15 table 17-13 uchannel receive and qchannel receive registers bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field uchannel receive 1 and 2 qchannel receive 1 and 2 reset undefined r/w read only bits1514131211109876543210 field uchannel receive 1 and 2 qchannel receive 1 and 2 reset undefined r/w read only addr mbar2 + 0x88: 0x8b (u channel1) mbar2 + 0xd8: 0xdb (u channel2) mbar2 + 0x8c: 0x8f (q channel 1) mbar2 + 0xdc: 0xdf (q channel 2) table 17-14 u channel receive and q channel receive bit descriptions bit name description uchannel receive 1 and 2 u channel receive register. contains next 4 u channel bytes. qchannel receive 1 and 2 q channel receive register. contains next 4 q channel bytes. table 17-15 cdtextcontrol bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field preseten presetcount(6:0) usync mode ebu2 usync mode ebu1 uchant xtim reset 0 000000000000 0 0 0 r/w r/w addr mbar2 + 0x92 table 17-16 cd-subcode register bit descriptions field bits mode description notes 15 preseten 1: preset free-running sync position counter 0: no action on free-running sync position counter. 2,3 14:8 presetcount (6:0) sync presetting count 1,3 2usyncmode ebu2 1: cd user channel reception 0: other data. 17-16 mcf5249um motorola digital audio interface (ebu) 17.3.1.8 u and q receive register interrupts uchannelrcvfull ? receive register full uchannelrcvoverrun ? overrun error qchannelrcvfull ? receive register full qchanneloverrun ? overrun error on q channel channelsyncfound ? received sync on u/q channel. channellengtherror ? set when channelsyncfound occurs when there are less than 32 bits waiting in qchannelreceive register, or less than 4 bytes in uchannelreceive, or when a syncing error is found. to regain correct syncing, u channel receive register and q channel receive register must be read to establish correct synchronization. on the input interface, 2 data receive registers are defined: 1. uchannelreceive ? 32-bit register to receive incoming subcode. 2. qchannelreceive ? 32-bit register to receive q channel of incoming subcode. the hardware associated with iec958 receiver u-channel reception is intended for reception of the following kind of data: cd or cd-compatible user channel subcode (p,q and r-w, or q and r-w). see the cd red book specification for a detailed description. other types of subcode. 17.3.1.9 behavior of user channel receive interface (cd data) this section details the behavior of the user channel receive interface on incoming cd user channel subcode in the iec958 receiver. this mode is selected if usyncmode (bit 1) in register cd-subcode control, is set. the cd subcode stream embedded into the iec958 user channel consists of a sequence of packets. every packet contains 98 symbols. the first two symbols of every packet are sync symbols and the other 96 symbols are data symbols. any sequence found in the iec958 u-channel stream starting with a leading one, followed by 7 information bits, is recognized as a data symbol. subsequent data symbols are separated by pauses. during the pause, zero bits are seen on the iec958 u-channel. data symbols come in msb first. the msb is the leading one and is always received as bit 7. 1 usyncmode ebu1 1: cd user channel reception 0: other data. 0 uchantxtim 0: timing to reg. uchanneltx from cd-text output interface 1: timing to reg. uchanneltx from ebu1 output interface 1. on read back, last written value is returned 2. on read back, zero is returned 3. presetcount (6:0) will only affect the free running counter when the register is written with preseten = ?1?. writing with preseten = ?0? does not affect the counter. table 17-16 cd-subcode register bit descriptions field bits mode description notes digital audio interface (ebu) motorola section 17 audio functions 17-17 when a long pause is seen between 2 subsequent data symbols, the iec958 receiver assumes the reception of one or more sync symbols. table 17-17 shows this functionality. the recognition of the number of sync symbols derives from the fact that the u-channel transmitter in the cd channel decoder will transmit one symbol on average every 12 iec958 channel bits. on this average rate, there is a tolerance of maximum 5%. the iec958 receiver is tolerant on symbol error. due to the physical nature of the transmission of the data over the cd disc, not more than one out of any 5 consecutive user channel symbols may be in error. the error may cause a change in data value, which is not treated by this interface, or it may cause a data symbol to be seen as a sync symbol, or a sync symbol to be seen as a data symbol. however, not more than one out of any 5 consecutive user channel symbols can be affected in this way. the iec958 user channel circuitry will recognize the 98-symbol packet structure, and send the 96 symbol payload to the coldfire application. the 96 symbol payload is transmitted to the coldfire using 2 registers: the uchannelrcv register ? in this register, data is presented 4 symbols at a time to the coldfire processor. every time 4 new valid symbols, received on the iec958 u-channel, are present, the uchannelrcvfull interrupt is asserted. for one 98-symbol packet, 96 symbols are carried across uchannelrcv. to transfer all this data, 24 uchannelrcvfull interrupts are generated. the qchannelrcv register ? in this register, only the q bit of the packet is accumulated. operation is similar to uchannelrcv. because only q-bit is transferred, only 96 q-bits are transferred for any 98-symbol packet. to transfer this data, 3 qchannelrcvfull interrupts are generated. when qchannelrcvfull occurs, it is coincident with uchannelrcvfull. there is only one qchannelrcvfull for every 8 uchannelrcvfull. the convention is that the most significant data is transmitted first, and is left-aligned in the registers. the timing, as it applies to packet boundary, is extracted by hardware.the last uchannelrcvfull corresponding to a given packet should be coincident with the last qchannelrcvfull. in this last u, q channel interrupt, symbols 95-98 are received, as are q-channel bits 67-98. the interrupts are coincident with channelsyncfound, flagging the last symbols of the current frame. when the start of a new packet is found before the current packet is complete (less than 98 symbols in the packet), the channellengtherror interrupt is set. the application software should read out uchannelrcv and qchannelrcv registers, discard the value, and assume the start of a new packet. table 17-17 correlation between zero bits and sync symbols no of u channel zero bits corresponding number of sync symbols 0-1 unpredictable, not allowed 2-10 0 11-22 1 23-34 2 35-45 3 > 45 unpredictable, not allowed 17-18 mcf5249um motorola digital audio interface (ebu) as previously mentioned, packet sync extraction is tolerant for single-symbol errors. packet sync detection is based on the recognition of the sequence data-sync-sync-data in the symbol stream, because this is the only syncing sequence that is not affected by single errors. if the sync symbol is not found 98 symbols after the previous occurrence, it is assumed to be destroyed by channel error, and a new sync symbol is interpolated. normally, only data bytes are passed to the application software. every data byte will have its most significant bit set. if sync symbols are passed to the application software (i.e., the processor), they are seen as all-zero symbols. sync symbols can only end up in the data stream due to channel error. 17.3.1.10 behavior of user channel receive interface (non-cd data) this section details the behavior of the user channel receive interface on incoming non-cd data. this mode is selected if usyncmode (bit 1) in register cd text control is set ?0?. in non-cd mode, the iec958 user channel stream is recognized as a sequence of data symbols. no packet recognition is done. any sequence found in the iec958 u-channel stream starting with a leading one, followed by 7 information bits, is recognized as a data symbol. subsequent data symbols are separated by pauses. during the pause, zero bits are seen on the iec958 u-channel. four consecutive data symbols seen in the iec958 u-channel stream are grouped together into the uchannelrcv register. first symbol is left, last symbol is right aligned. whenever uchannelrcv contains 4 new data symbols, uchannelrcvfull is asserted. in this mode, the operation of qchannelrcv and associated interrupt qchannelrcvfull is reserved, undefined. also reserved, undefined is the operation of channellengtherror and channelsyncfound. the u-channel is extracted and output by the iec958 receive block on eburcvuchannelstream. processing is done by the cd-subcode as described in section 17.4 processor interface overview . 17.3.2 iec958 transmit interface the iec958 interface provides the necessary features to allow transmitting of digital data according to the iec958 specification with the exception that only 20-bit data is supported. the 4 lsb?s of the 24-bit data word are always ?0?. in addition to data, the interface allows for transmission of the c- and u-channels and control over the valid flag. the transmitter has 2 physical outputs. one with consumer c-channel format and one with ?professional? c-channel format. on the u-channel, only the cd user data format is supported. note: ebuout1 and ebuout2 will output a clock signal just after reset and before they can be configured as gpio. the frequency of the clock output will be crin/16. 17.3.2.1 transmit ?c? channel there are two iec958 outputs. the difference is the formatting of the ?c? channel. there are also two iec958 ?c? channel control registers, ebu1txcchannel1 and ebu1txcchannel2. the following tables show the formatting of both iec958 outputs. digital audio interface (ebu) motorola section 17 audio functions 17-19 17.3.2.2 iec958 transmitter exception conditions there are three transmitter exception conditions: 1. transmit fifo underrun 2. transmit fifo overrun 3. transmit fifo empty 17.3.2.3 iec958-3 ed2 and tech 3250-e standards compliance the iec958 transmitter is compliant with iec958-3 ed2 and tech 3250-e documents from international iec standards committee and european broadcasting union organizations. the iec958 transmitter implementation allows any sample frequency. operation is guaranteed up to a maximum incoming transmit clock of 1/3 of the 48 mhz system clock. the mark/space ratio of the transmit clock must be equal to or better than 38/62. table 17-18 ebu1txcchannel registers addresses address name width description reset value access mbar2 + 0x28 ebu1txc channel1 32 ?c? channel bit settings for iec958 transmitter - consumer format undefined rw mbar2 + 0x2c ebu1txc channel2 32 ?c? channel bit settings for iec958 transmitter - professional format undefined rw table 17-19 formatting of ebuout1 (consumer ?c? channel) iec958 bits field name description taken from, 0:31 control relevant data ebu1txcchannel1(31:0) 32:191 always 0 note: 1. ordering of bits in ebu1txcchannel1 is msb sent ou t first. so, ebu1txcchannel1(31) is sent out as iec958 bit 0. table 17-20 formatting of ebuout2 - professional ?c? channel iec958 bits field name description taken from, 0:23 contro l relevant data ebu1txcchannel2(31:8) 24:183 always 0 184:191 crc using polynomial x**8+x**4+x**3+x**2+1 ebu1txcchannel2(7:0) note: 1. ordering of bits in ebu1txcchannel2 is msb out first. so, ebu1txcchannel2(31) is sent out as iec958 bit 0. note: 2. iec958 bits 184:191 are copied from ebu1txcchannel2(7:0). for compliancy to ebu tech 3250 document, the bits 184:191 should be filled in as the crc of the complete c-channel frame. this is not done in hardware. a software routine should be used to make sure ebu1txcchannel2(7:0) reflects the correct value. note: 3. the ebuout2 signal is only used on the 160 mapbga package. 17-20 mcf5249um motorola digital audio interface (ebu) 17.3.2.4 transmission of u-channel and cd subcode data the user channel transmitter is intended to assemble the cd subcode stream, and conform to the iec958 cd standard specification. the generation of the data needs to be done in software and loaded into hardware registers. the mcf5249 has provisions to insert this cd subcode stream into the outgoing iec958 stream, or to transmit it over a dedicated 3-wire interface, called the cd-subcode interface. the 3-wire cd-subcode is intended to connect philips semiconductor cd encoder devices. this combined interface provides output formats for both cd-subcode and iec958 u-channel. the same data is used for both output formats. figure 17-4 cd-subcode interface table 17-21 uchannel transmit register address name width description reset value access mbar2 bas + 0x84:0x87 uchannel transmit 32 u channel transmit register. contains next 4 u channel bytes. -- rw table 17-22 cd-subcode register bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field preset en presetcount(6:0) usync mode ebu1 usync mode ebu1 uchan txtim reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r/w r/w addr mbar2 + 0x92 cd text transmit u channel transmit register u channel receive register q channel receive register ebu u channel in to ebu transmitter u channel source selector rck sfsy sub r digital audio interface (ebu) motorola section 17 audio functions 17-21 17.3.3 cd subcode interrupts the following interrupts are associated with the cd subcode data: uchanneltxempty ? register is empty, needs re-load. uchanneltxunderrun ? underrun error on register. uchanneltxnextfirstbyte ? received indication from cd-subcode output interface that next word to be written contains first byte of the 96-byte u-channel frame.cd subcode interface: sfsy, rck and subr note: the subr, rck, and sfsy signals are only used on the 160 mapbga package. figure 17-5 data format on cd-subcode interface out rck is the incoming clock from the channel encoder. sfsy is used to flag the first symbol bit, and first packet symbol. during the first bit of every symbol, sfsy is low, during the first two bits of the first symbol of every packet, sfsy is low. subr is the data out, used to transmit outgoing data in serial form. the most significant bit is transmitted first. note: the subr, rck, and sfsy signals are only used on the 160 mapbga package. rck is an input, sfsy and subr are outputs. cd user channel subcode is transmitted out of the 3-wire cd subcode interface. this user channel subcode needs to be assembled by the coldfire processor application software. the cd-subcode format has a 98-symbol packet structure. of these 98 packets, the first 2 symbols are sync symbols, followed by 96 8-bit data symbols. the boundaries of the 98-symbol packets are determined by free-run counters. the first symbol of any packet is transmitted with the special sync sequence on sfsy. the first and second symbols are all-0 symbols. the other 96 symbols need to be uploaded by the application software in register uchanneltransmit. upload is done by application software handshaking to interrupt uchanneltxempty. if this interrupt is set, the application software uploads 4 symbols of the current user channel packets into register uchanneltx. the interrupt uchanneltxnextfirstbyte flags the start of a new u channel packet. it is always coincident with uchanneltxempty, and signal that the first 4 symbols of a new packet need to be loaded into uchanneltx. the following pseudo-code reacts on both interrupts. one interrupt handler can take care of both uchanneltxempty and uchanneltxnextfirstbyte. this last interrupt is not enabled. rck sfsy subr (mcf5249 in) (mcf5249 out) ( mcf5249 out) 17-22 mcf5249um motorola digital audio interface (ebu) if(uchanneltxempty interrupt) then if(uchanneltxnextfirstbyt interrupt set also) then reset this interrupt synchronize pointer to sent out new frame end if ; load uchanneltransmit with data from pointer update pointer reset interrupt end if ; 17.3.3.1 free running counter synchronization there is a synchronization issue on start-up between the mcf5249 and some channel encoders. on start-up, the rck clock is kept silent. at a certain point in time, the cdr60 1 will start clocking the rck, and then it will require that the first symbol transmitted from the mcf5249 to the cdr60 is a sync symbol. if this is not the case, the cdr60 fails to synchronize. to solve the synchronization issue, the counter that determines the sync position can be preset using the register cdtextcontrol (see table 17-15 ). 17.3.3.2 controlling the sfsy sync position when rck is not clocking, it is possible to control the subcode byte number that will be sent out next by the cd-subcode interface by writing cdtextcontrol with preseten set ?1?. when 0 is written to presetcount, the next byte sent out will be a cd-subcode sync byte. (sfsy low). when a value (97 - i) is written to presetcount, i non-sync bytes are transmitted, followed by a sync byte. after writing to cdtextcontrol with preseten set to ?1?, next bit out will always be the first bit of a new byte. writing cdtextcontrol with preseten set to ?1?, while rck is running, will result in unpredictable, undefined operation. 17.3.4 inserting cd user channel data into iec958 transmit data source selection of data transmitted into the user channel of iec958 transmitter is selected by bits (1,0) of register ebuconfig. when selected source is iec958 receiver, every user channel data byte received into the input iec958 user channel, is inserted into the outgoing stream at approximately. the same time it was found in the incoming stream. when selected source is cd-subcode, every data byte transmitted over the cd-subcode output is also inserted into the iec958 out stream. the most significant bit of every byte is transmitted as a ?1?. all sync symbols are transmitted as all-0. in case rck clock is not present, it is still possible to use the cd-subcode interface to assemble the outgoing iec958 user channel data. in this case, bit uchantxtim in register cdtext config must be set ?1? (see table 17-38 ). it will cause the timing to the cd-subcode registers to be controlled by the iec958 transmitter. one symbol (data or sync) will be transmitted into the iec958 output every 12 user channel data bits. 1. cdr60 is the informal name for philips cd-r channel encoder processor interface overview motorola section 17 audio functions 17-23 17.4 processor interface overview the interface between the processor and the audio modules is given in this section. figure 17-6 shows a simplified picture of the interface between the audio modules and the processor core. note: the audio module register addresses are relative to the mbar2 register. figure 17-6 processor/audio module interface 17.4.1 data exchange register descriptions table 17-23 shows the data exchange registers. to read/write data to/from the audio modules use the registers as shown in table 17-42 . table 17-23 data exchange register descriptions address mbar2 + name width description reset value access 0x34 0x38 0x3c 0x40 pdir1-l 32 processor data in left. multiple address to read this register allows movem instruction to read fifo. -r 0x44 0x48 0x4c 0x50 pdir3-l 32 processor data in left. multiple address to read this register allows movem instruction to read fifo. -r 0x54 0x58 0x5c 0x60 pdir1-r 32 processor data in right multiple address to read this register allows movem instruction to read fifo. -r processor core control registers data exchange registers interrupt registers data[31:0] ctrl (r/w, etc.) address[7:0] 17-24 mcf5249um motorola processor interface overview 17.4.2 data exchange register overview pdor1-l, pdor1-r : (processor data out 1). these are 2 32-bit registers. both registers have 4 consecutive longword addresses assigned (multiple decode). this allows easy transfer of multiple samples using movem instructions. data written to these registers will end in one of the fifo ?s ( figure 17-1 ) 12, 14, 17, 17a, 17b or 25 . the format of data in the registers is defined below. pdor2-l, pdor2-r : (processor data out 2). same function as pdor1. also double 32-bit registers (pdor2-l and pdor2-r), occupying 4 consecutive longword addresses (multiple decoded.) data written to it will end in one of the fifo ?s. ( figure 17-1 ) 12,14,17, 17a, 17b or 25 . pdor3 : (processor data out3). same function as pdor1. it is a single 32-bit register which contains both left + right data in 16-bit precision occupying 4 consecutive longword addresses. data written to it will end in one of the fifo ?s. ( figure 17-1 ) 12,14, 17a, 17b or 25 . pdir1-l, pdir1-r (processor data in). used to transfer data to the processor. these 2 32-bit register, each occupying 4 consecutive longword addresses are used to read data from the audio bus. data flowing in is selected by source multiplexer 16a . control via register dataincontrol(12,2:0) . ( table 17-24 ). 0x64 0x68 0x6c 0x70 pdir3-r 32 processor data in right multiple address to read this register allows movem instruction to read fifo. -r 0x34 0x38 0x3c 0x40 pdor1-l 32 processor data out 1 left. multiple address to write this register allows movem instruction to write fifo. undef w 0x44 0x48 0x4c 0x50 pdor1-r 32 processor data out 1 right multiple address to write this register allows movem instruction to write fifo undef w 0x54 0x58 0x5c 0x60 pdor2-l 32 processor data out 2 left multiple address to write this register allows movem instruction to write fifo undef w 0x64 0x68 0x6c 0x70 pdor2-r 32 processor data out 2 right multiple address to write this register allows movem instruction to write fifo undef w 0x74 0x78 0x7c 0x80 pdor3 32 processor data out 3 left + right undef w 0x74 0x78 0x7c 0x80 pdir2 32 processor data in 3 left + right undef r note: 1. multiple addresses for pdor/pdir fields are intended for easy use of movem instruction to move data into and out of the fifo ?s. the data read at each address of any range is exactly the same, being the next sample in/out of the fifo. there is no difference in fifo operation between a read at address e.g. 0x74, 0x78, 0x7c. note: 2. there is memory overlaps between pdir?s and pdor?s. pdor?s cannot be read, pdir cannot be written to. table 17-23 data exchange register descriptions address mbar2 + name width description reset value access processor interface overview motorola section 17 audio functions 17-25 pdir2 (processor data in). same function as pdir1. single 32-bit register contains both left + right in 16-bit precision. data flowing in is selected by source multiplexer 16 . control via register dataincontrol(13,5:3) ( table 17-24 ) pdir3-l, pdir3-r (processor data in). this function is identical to pdir1. data flowing in is selected by source multiplexer 16b . control via register dataincontrol(19:16) . ( table 17-24 ) 17.4.2.1 data in selection the dataincontrol register determines what data will be in the pdir1 input data fifo, in pdir2 input data fifo, and in the pdir3 input data fifo. all fifo?s are six-deep, and have programmable ?full? indication. note: the dataincontrol register bits 7:6 allow selection when fifo full flag is set. this is necessary due to polling. it may b e necessary to service the fifo when it is less than completely full. for pdir2, only interrupt-driven and dma-driven read-out is supported. table 17-24 dataincontrol register bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 1 7 16 field pdir3 zero ctrl pdir3 reset pdir3 full interrupt select pdir3 reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r/w r/w bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field pdir2 full interrupt select select pdir2 select pdir1 pdir2 zero ctrl pdir1 zero ctrl pdir2 reset pdir1 reset pdir full interrupt select select pdir2 select pdir1 reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r/w r/w addr mbar2 + 0x30 (reset 0x00) table 17-25 dataincontrol bit descriptions field field name description reset 23 pdir3 zero control 0: normal operation 1: always read zero from pdir3 0 22 pdir3 reset 0: normal operation 1: reset pdir3 to one sample remaining 0 21:20 pdir3 full interrupt select 00: full interrupt if at least 1 sample in fifo 01: full interrupt if at least 2 samples in fifo 10: full interrupt if at least 3 samples in fifo 11: full interrupt if at least 6 samples in fifo 00 19:16 select pdir3 0000: off 0001: pdor1 0010: pdor2 0011: unused 0100: iis1rcvdata 0101: iis3rcvdata 0110: iis4rcvdata 0111: ebu1rcvdata 1000: ebu2rcvdata 000 17-26 mcf5249um motorola processor interface overview 15:14 pdir2 full interrupt select 00: full interrupt if at least 1 sample in fifo 01: full interrupt if at least 2 samples in fifo 10: full interrupt if at least 3 samples in fifo 11: full interrupt if at least 6 samples in fifo 00 11 pdir2 zero control 0: normal operation 1: always read zero from pdir2 0 10 pdir1 zero control 0: normal operation 1: always read zero from pdir1 0 9 pdir2 reset 0: normal operation 1: reset pdir2 to one sample remaining 0 8 pdir1 reset 0: normal operation 1: reset pdir1 to one sample remaining 0 7:6 pdir1 full interrupt select 00: full interrupt if at least 1 sample in fifo 01: full interrupt if at least 2 samples in fifo 10: full interrupt if at least 3 samples in fifo 11: full interrupt if at least 6 samples in fifo 00 13,5:3 select pdir2 0 000: off 0 001: pdor1 0 010: pdor2 0 011: unused 0 100: iis1rcvdata 0 101: iis3rcvdata 0 110: iis4rcvdata 0 111: ebu1rcvdata 1 000: ebu2rcvdata 000 12,2:0 select pdir1 0 000: off 0 001: pdor1 0 010: pdor2 0 011: unused 0 100: iis1rcvdata 0 101: iis3rcvdata 0 110: iis4rcvdata 0 111: ebu1rcvdata 1 000: ebu2rcvdata 000 table 17-25 dataincontrol bit descriptions field field name description reset processor interface overview motorola section 17 audio functions 17-27 17.4.3 pdir and pdor field formatting each pdir, pdor 32-bit register contains only 20 relevant data bits. formatting is done as follows: note: 1. l18 is bit 18 of left sample, ~l19 is inverse of bit 19 of left sample, r18 is bit 18 of right sample. note: 2. if incoming/outgoing interface use 16, 18 bits, data is aligned at the msb side. lsb ?s d1-d0 or d3-d0 will read all-ze ro. written values are disregarded. note: 3. pdor3, pdir2 use only 16 msb of both left and right. note: 4. inversion of msb ?s l19 and r19 translates the format from 2-complement to unsigned. (the continuous range e.g. -0x8000 to +7fff is translated to 0 to +0xffff) 17.4.4 overrun and underrun with pdir and pdor registers all pdor and pdir registers have different fifos for left and right channel. as a result, there is always the possibility that left and right fifos may go out of sync due to fifo underruns and fifo overruns that affect only one part (left or right) of any fifo. to prevent this from happening, two hardware mechanisms are available: 1. if pdir1, pdir2, or pdir3 fifo overrun occurs on, as an example, the right half of the fifo, the sample that caused the overrun is not written to the right half (due to overrun). special hardware will make sure the next sample is not written to the left half of the fifo. if the overrun occurs on the left half of the fifo, the next sample is not written to the right half of the fifo. 2. if iis1 or iis2 tx fifo, or ebu tx fifo underruns on, for example, the right half of the fifo, no sample leaves that fifo. (because it was already empty.) special hardware ensures that the next sample read from the left fifo will not leave the fifo. (no read strobe is generated). if the underrun occurs on the left half of the fifo, next read strobe to the right fifo is blocked. table 17-26 pdir1-l, pdir3-l, pdor1-l, pdor2-l formatting bit 31 bit 30 bit 29 bit 28 bit 27 bit 26 bit 25 bit 24 bit 23 bit 22 bit 21 bit 20 bit 19 bit 18 bit 17 bit 16 ~l19 l19 l19 l18 l17 l16 l15 l14 l13 l12 l11 l10 l9 l8 l7 l6 bit 15 bit 14 bit 13 bit 12 bit 11 bit 10 bit 9 bit 8 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 l5 l4 l3 l2 l1 l0 0 0 0 0 0 0 0 0 0 0 table 17-27 pdir1-r, pdir3-r, pdor1-r, pdor2-r formatting bit 31 bit 30 bit 29 bit 28 bit 27 bit 26 bit 25 bit 24 bit 23 bit 22 bit 21 bit 20 bit 19 bit 18 bit 17 bit 16 ~r19 r19 r19 r18 r17 r16 r15 r14 r13 r12 r11 r10 r9 r8 r7 r6 bit 15 bit 14 bit 13 bit 12 bit 11 bit 10 bit 9 bit 8 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 r5 r4 r3 r2 r1 r0 0 0 0 0 0 0 0 0 0 0 table 17-28 pdir2, pdor3 formatting bit 31 bit 30 bit 29 bit 28 bit 27 bit 26 bit 25 bit 24 bit 23 bit 22 bit 21 bit 20 bit 19 bit 18 bit 17 bit 16 l19 l18 l17 l16 l15 l14 l13 l12 l11 l10 l9 l8 l7 l6 l5 l4 bit 15 bit 14 bit 13 bit 12 bit 11 bit 10 bit 9 bit 8 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 r19 r18 r17 r16 r15 r14 r13 r12 r11 r10 r9 r8 r7 r6 r5 r4 17-28 mcf5249um motorola processor interface overview 17.4.5 automatic resynchronization of fifos an automatic fifo resynchronization feature is available on the mcf5249. it can be enabled and disabled separately for every fifo. if enabled, the hardware will check if the left and right fifos are in sync, and if not, it will set the filling pointer of the right fifo to be equal to the filling pointer of the left fifo. the operation is shown in figure 17-7 . every fifo auto-resync controller has a state machine with three states: 1. off 2. stand-by 3. on in the on state, the filling of the left fifo is compared with the filling of right, and if they are not equal, right is made equal to left, and an interrupt is generated. figure 17-7 automatic resynchronization fsm of left-right fifos the controller will stay in off state when the feature is disabled. when not disabled, the state machine will go to the off state on any processor read or write to the fifo. it will go from on or off to standby on any left sample read from iis, iis2, and ebu tx fifos, or on any left sample write to pdir1, pdir2, pdir3 fifos. the controller will go from standby to on on any right sample read from iis1, iis2 and ebu tx fifos, or on any right sample write to pdir1, pdir2 and pdir3. table 17-29 audioglob register bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field pdir3 fifo auto sync audiotick source ebu2 ext ebu1 tx auto sync iis2 fifo auto sync pdir2 fifo auto sync pdir1 fifo auto sync audio_tick count audiotick source reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r/w r/ w r/ w r/ w r/w r/w r/w r/w r/w r/w r/w r/ w r/ w r/ w r/ w r/ w r/ w addr 0xcc off standby on read left sample from iis1, iis2, ebu write left sample to pdir1, pdir2 processor write to iis1, iis2, ebu fifo processo read from pdir1, pdir2 read left sample from iis1, iis2, ebu write left sample to pdir1, pdir2 read right sample from iis1, iis2, ebu write right sample to pdir1, pdir2 processor interface overview motorola section 17 audio functions 17-29 table 17-30 audioglob register fields (0xce) field - bits name description reset notes 12 pdir3 fifo auto sync 0: auto synchronization off 1: auto synchronization on 0 10 ebu tx auto sync 0: auto synchronization off 1: auto synchronization on 0 9 iis2 fifo auto sync 0: auto synchronization off 1: auto synchronization on 0 8 iis1 fifo auto sync 0: auto synchronization off 1: auto synchronization on 0 7 pdir2 fifo auto sync 0: auto synchronization off 1: auto synchronization on 0 6 pdir1 fifo auto sync 0: auto synchronization off 1: auto synchronization on 0 5:3 audio tick count 000: 1. interrupt for every event 001: 2 interrupt for every 2 events 010: 3 011: 4 100: 5 other: reserved, unused 000 11, 2:0 audio tick source 0 000: off 0 001: iis1 tx right fifo / read 0 010: iis2 tx right fifo / read 0 011: ebu tx right fifo / read 0 100: iis1 rcv data 0 101: iis3 rcv data 0 110: iis4 rcv data 0 111: ebu1 rcv data 1 000: ebu2 rcv data 000 note: the automatic fifo resynchronization can be switched on, and will avoid all mismatch between left and right fifo ?s, if the software obeys following rules: 1. when left data is read or written to the left fifo, in the same place of the program, data must be read or written to the right fifo. maximu m time difference between left and right is 1/2 sample clock. (e.g. if sample frequency is 44 khz, approximately 10 micro-seconds. for 88 khz, approximately 5 micro-seconds.) 2. write/read data to fifo ?s at least 2 samples at the time. if there is a mis-match left-right, the resync logic may go on only 1 sample clock after last data is read/written to the fifo. also acceptable is polling the fifo, if at least part of the time 2 samples will be read/written to it. 17-30 mcf5249um motorola processor interface overview 17.4.6 audio interrupts 17.4.6.1 audiotick interrupts the audio tick interrupt is an interrupt to sustain an interrupt routine that is synchronous with one of the audio interfaces, but not directly related to any fifo being full or empty. two fields control how this interrupt is generated: 1. the source field controls the source event. 2. the count field controls the number of events (sample pairs) between any two audiotick interrupts. for example, if the source is set to iis1 tx fifo / read, and count is set to three, the interrupt will pulse after every three read strobes to the iis1 tx fifo. even if the fifo is in reset state, the interrupt will continue running. 17.4.6.2 pdir1, pdir2, and pdir3, exceptions with fifos feeding data to pdir registers, three exceptions are associated. 1. full 2. under/over 3. resync when the full condition is set for processor data input registers, the mcf5249 processor should read data from the fifo, before overrun occurs (this is within 1/2 sample period). reading of data should be done using 32-bit operands (ex. move.l instruction). when full is set, and the fifo contains, for example six samples, it is acceptable for the software to read the first six samples from the left address, followed by six samples from the right address, or six samples from the right address, followed by six samples from the left address, or one sample left, followed by one sample right repeated six times. there is no order specified. the implementation for pdir1 is a double fifo, one for left and one for right. the full condition is set when both fifos are full. the underrun/overrun condition is set when one of the fifos actually underrun or overrun. the resync interrupt is set when the hardware took special action to resynchronize left and right fifos. 17.4.6.3 pdor1, pdor2, and pdor3 exceptions three exceptions are associated with fifos that can be written from pdor1, pdor2, pdor3: 1. empty 2. under/over 3. resync when the empty condition is set for processor data output registers, the coldfire processor should write data to the fifo, before underrun occurs. writing of data should be done using move long or movem instructions, in any case with long-word oriented instructions. when empty is set, and, for example, six samples need to be written, it is acceptable for the software to write first six samples from the left address, followed by six samples from the right address, or one sample left, followed by one sample right repeated six times. note: the left should be written before the right. processor interface overview motorola section 17 audio functions 17-31 the implementation of all data out fifos is a double fifo, one for left and one for right. the empty exception is set when both fifos are empty. the underrun/overrun exception is set when one of the fifos is underrun or is overrun. resync is set when the hardware resynchronizes left and right fifos. on receiving an underrun/overrun interrupt, synchronization between left and right words in the fifos may be lost. synchronization will not be lost when the underrun or overrun comes from the audio side of the fifo. if the processor reads or writes more data from, for example, the left than from the right, synchronization will be lost. if automatic resynchronization is enabled, and if the software obeys the rules to let this work, resynchronization will be automatic. table 17-31 interrupt register description (0x94, 0x98) bit interrupt name description how to clear 31 iis1txunov iis1 transmit fifo under/overrun reg. intclear 30 iis1txresyn iis1 transmit fifo resync reg. intclear 29 iis2txunov iis2 transmit fifo under/overrun reg. intclear 28 iis2txresyn iis2 transmit fifo underrun reg. intclear 27 ebutxunov iec958 transmit fifo under/overrun reg. intclear 26 ebutxresyn iec958 transmit fifo resync reg. intclear 25 ebucnew iec958 receiver change in value of control channel reg. intclear 24 iec958valnogood iec958 validity flag no good reg. intclear 23 ebusymerr iec958 receiver found illegal symbol reg. intclear 22 ebubiterr iec958 receiver found parity bit error reg. intclear 21 uchantxem uchanneltransmit register empty write to tx reg 20 uchantxunder uchanneltransmit register underrun reg. intclear 19 uchantx-nextfirst uchanneltransmit register next byte will be first write to tx reg 18 uchanrcvfull uchannelreceive register full read rcv reg 17 uchanrcvover uchannelreceive register overrun reg. intclear 16 qchanrvfull qchannelreceive register full read rcv reg 15 qchanoverrun qchannelreceive register overrun reg. intclear 14 uqchansync u/q channel sync found reg. intclear 13 uqchanerr u/q channel framing error reg intclear 12 pdir1unov processor data input underrun/overrun reg intclear 11 pdir1resyn processor data input resync reg intclear 10 pdir2unov processor data input underrun/overrun reg intclear 9 pdir2resyn processor data input resync reg intclear 8 audiotick audio tick interrupt reg intclear 7 6 5 17-32 mcf5249um motorola processor interface overview 17.4.6.4 audio interrupt routines and timing usually, the mcf5249 processor will run an audio interrupt routine. every time the audio interrupt routine runs, it will process 2, 3, or 4 audio samples, and send this many samples to one or more pdor output registers. also, the audio interrupt routine will read one or more pdir registers until empty. in the audio interrupt routine, typically at the beginning, the pdir registers are read until empty, while the pdor registers are written at the end of the routine when all calculations are completed. due to this calculation latency, there is a delay between entering the audio interrupt routine and the filling of the transmit fifos. due to this delay, it is difficult to ?fire? the audio interrupt routine on a transmit fifo empty interrupt. because of the extra delay before the data is written, the transmit fifo will underrun before any data is written. to make it easy for the programmer, the audiotick interrupt was added. to start the audio interrupt routine, use the following sequence: 1. reset the transmit fifos 2. program the transmit fifos to correct source, de-assert reset on transmit fifos 3. reset the pdir fifos 4. load audio interrupt routine in on-chip sram 5. release reset for the pdir fifos and enable audiotick interrupt the transmit fifos have a special feature. after the software releases the reset to them, they will stay in reset until the audio interrupt routine writes data to them for the first time. so, during step 2 of above mentioned start-up procedure, all transmit data out fifos are set in reset, with one sample remaining. they will stay in this state, until the audio interrupt routine writes data to them. at this point in time, they are then filled up with extra 2,3, or 4 samples to a total of 3,4, or 5 samples. also, the first data write to the fifos releases the reset, and starts transmission of fifo data on the corresponding transmit output. (iis1, iis2 or iec958). the next time that data is written to the fifos in the audiotick interrupt routine, 2,3, or 4 samples have been transmitted and the fifo is ready to accept new data. to work properly, the jitter from one audiotick write point to the next is important. jitter should be lower than 1 sample period if data is written in groups of 2 or 3 samples to the transmit fifos, and lower than 1/2 sample period if data is written in groups of 4 samples to the transmit fifos. the receive fifos (pdir) don?t have an auto-reset-de-assert mechanism, and should be released out of reset just before enabling audiotick interrupt. figure 17-8 shows the timing (relative to the word clock) of the empty, under-run, and audio tick interrupts. each fifo holds up to six audio samples (left and right). 4 iis1txempty iis 1 transmit fifo empty write to fifo 3 iis2txempty iis 2 transmit fifo empty write to fifo 2 ebutxempty iec958 transmit fifo empty write to fifo 1 pdir2 full processor data input full read from pdir2 0 pdir1 full processor data input full read from pdir1 table 17-31 interrupt register description (0x94, 0x98) bit interrupt name description how to clear processor interface overview motorola section 17 audio functions 17-33 the empty interrupt occurs when there is still one right sample left to be transmitted, thus giving the system one audio sample length to fill the fifo back-up. the under-run interrupt occurs when there are no samples left to be transmitted. while this is a situation that should be taken seriously, it will rarely occur. however, should this happen, the system will continue to repeat the last sample until the fifo buffer has new data. the audio tick interrupt was introduced to aid a busy system by allowing the interrupt to occur after a number of (programmable) sample pairs. in this example, the audio tick interrupt has been set to trigger after the 4th sample pair. this gives the system up to two audio sample pairs to respond and fill the fifo. this avoids the under-run issue. the decision to use the audio tick interrupt as apposed to the empty interrupt is dependent on the system and the reaction time of that system. therefore, it is not expected that the audio tick interrupt need to be employed in all systems. figure 17-8 audio transmit / receive fifos 17.4.7 cd-rom block encoder and decoder the processor interface registers pdor3 and pdir2 are equipped with a cd-rom block encoder/decoder. the two interfaces are fully independent. one control register is associated with the interface. table 17-32 blockcontrol register bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field decode swap decode sync allow decode de- scramble decode mode encode swap encode sync allow encode scramble encode mode re- set 0000000000000000 r/w r/w addr mbar2 bas+ 0xc8 word clock 1l 1r 2l 3r 3l 2r 4l 4r 5l 6r 6l 5r programmable audio tick interrupt fifo empty interrupt fifo under-run interrupt 17-34 mcf5249um motorola processor interface overview table 17-33 blockcontrol bit descriptions bit number bit name description reset notes 14,15 decode swap see note 1. block decode swap control.( 00 1 13 decode-sync enable see note 2. 1 = sync detection enabled. 0 = sync detection disabled 02 11 decode enable see note 3. 1 = descramble enabled. 0 = escramble disabled 03 9, 10 decode mode see note 4. 00: no crc check 01: mode 1 10: mode 2, form 1 11: mode 2, form 2 00 4 6, 7 encode swap see note 1. block encode swap control 00 1 5 encode sync enable see note 2. 1 = outgoing sync detecting enabled. 0 = outgoing sync detecting disabled 02 3 encode enable see note 3. 1 = scramble active 0 = scrambling inactive 03 1, 2 encode mode 00: no crc instructed 01: mode 1 10: mode 2, form 1 11: mode 2, form 2 00 4, 5 note: 1. see table 17-34 for definition of how swap is done. note: 2. decode sync allow and encode sync allow define whether the interfaces recognize the cd-rom syncs embedded in the cd-rom sectors. if this bit is switched on, then the interface will recognize the start of a new sector after finding the sync sequence in the data. if the bit is switched off, or if no sync sequence is found, sector start is assumed to be one sector length (2352 bytes) after the previous sector. note: 3. descrambling/scrambling control if cd-rom descrambling/scrambling is done. note: 4. mode selection determines how crc is calculated. the crc depends on cd-rom mode/form, as defined in cd standards. note: 5. inserted crc will over-write processor written data. (processor sets crc to any value, logic overwrites this.) processor interface overview motorola section 17 audio functions 17-35 figure 17-9 block decoder 17.4.7.1 cd-rom decoder interrupts the block decoder can detect and signal sync patterns and error conditions. the following conditions are flagged in status bits and each of these can generate an interrupt. all interrupts occur when the corresponding data word reaches the output of the fifo. newblock interrupt ? set when the next longword to be read is first word of new block. nosync interrupt ? set when the next longword to be read is first word of new block, and no valid sync pattern was found before the start of this new block in the stream. table 17-34 swap control in cd-rom encoder/decoder swap field swap action 00 dataout(31:0):= datain(31:0) 01 dataout(31:16):= datain(15:0) dataout(15:0):= datain(31:16) 10 dataout(31:24):= datain(23:16) dataout(23:16):= datain(31:24) dataout(15:8):= datain(7:0) dataout(7:0):= datain(15:8) 11 dataout(31:24):= datain(7:0) dataout(23:16):= datain(15:8) dataout(15:8):= datain(23:16) dataout(7:0):= datain(31:24) note: 1. notation used is 32-bit words. bits31-16 are part of the left sample, bits 15-0 are part of the right sample. swap bytes swap select descramble on/off select sync recognition fifo crc check mode form settings internal audio bus (data) newblockint ilsyncint nosyncint crcerrorint 1 2 3 45 6 sync settings 17-36 mcf5249um motorola dma channel interaction ilsync interrupt ? set when the next longword to be read is first word of new block, and length of previous block was not equal to 2352 bytes, the nominal block length. crcerror interrupt ? set when the next longword to be read is first word of new block, and crc check on previous block failed. figure 17-10 block encoder the block encoder works on the incoming pdor3 stream. first, crc insertion is done in the crc calculate and insert ( 1 ), next the stream is scrambled in scramble ( 2) , and finally it is byte-swapped in byte swaps ( 3) . all three operations can be configured by writing to the blockcontrol register. crc insertion and scrambling are done as described in cd yellow book. the crc insertion 1 and the scrambling 2 are done on a block-by-block basis. a block is normally 2352 bytes long. a block starts after the so-called sync pattern , ?00ffffff-ffffffff-ffffff00?. to detect start of a new block, two mechanisms are build into the encoder. first long-word of new block is assumed after finding the sync pattern ?00ffffff-ffffffff-ffffff00? first long-word of new block is assumed exactly 2352 bytes after first longword of previous block. this second detection mechanism builds in immunity for corrupted syncs. even if the sync is corrupted, the block encoder will correctly find the start of the new block. 17.4.7.2 cd-rom encoder interrupts newblock interrupt ? active when transmission of new block is started. no direct synchronization with data written to the transmit fifo. nosync interrupt ? set when the sync pattern was not recognized for the current newblock interrupt. ilsync interrupt ? set when the previous block did not have the correct length. (length different from 2352 bytes). 17.5 dma channel interaction it is possible to use dma to transfer data to/from the fifos in the audio interface module. only pdir2 and pdor3 registers support dma, as others need more than 1 long-word to transfer data to/from the fifo and cannot be used with dma operation. swap bytes swap select scramble on/off select 23 processor data crc calculate and insert sync recognition 4 sync settings to audio data bus 1 newblockint ilsyncint nosyncint phase/frequency determination and xtrim function motorola section 17 audio functions 17-37 operation is as follows: ? if pdir2 is full and dmaconfig(1) is set to ?0?, dma1req is activated. ? if pdir2 is full and dmaconfig(0) is set to ?0?, dma0req is activated. ? if the fifo connected to pdor3 is empty, and dmaconfig(1) is set ?1?, dma1req is activated. ? if the fifo connected to pdor3 is empty, and dmaconfig(0) is set to ?1?, dma0req is activated. both dma1req and dma0req can be routed to dma channel 0 or dma channel 1. for details, see description of coldfire dma controller. 17.6 phase/frequency determ ination and xtrim function these features are necessary so that users can determine when a software sample rate convertor should be enabled and provide the necessary control to steer the sample rate convertor clock (when the incoming sample rate is other then 44.1 khz). in addition, users can also utilize this function to determine when the incoming iec958 clock does not match the phase of the xtal oscillator and use the xtrim function to trim the external oscillator to match (within a 150ppm range). typically, when the iec958 input is being used, the xtal requires trimming to match but this is only when the source is completely external to the application. when the source is internal to the application, such as from a cd player controlled by the mcf5249, then the input sample rate does not need to match the output sample rate, so they can be asynchronous. when fifo under-run or over-run occurs, request that the data lost is re-read by the system. 17.6.1 incoming source frequency measurement the pll maintaining phase relation between incoming source signal and internal signal is mainly digital. it is necessary, however, to measure phase/frequency of the incoming signal in relationship with the crystal table 17-35 dma config register address bits 7 6 5 4 3 2 1 0 field dma1req dma0req reset 00 r/w r/w r/w addr mbar2 + 0x9f table 17-36 dma config bit descriptions bit name description note s dma1req 0 = pdir2 1 = pdor3 1, 2, 3 dma0req 0 = pdir2 1 = pdor3 1, 2, 3 17-38 mcf5249um motorola phase/frequency determination and xtrim function clock in order to be able to steer the sample rate convertor clock. the circuit shown in figure 17-11 is used for maintaining phase relationship. figure 17-11 frequency measurement circuit associated with it, are two registers. (see table 17-37 ). the circuit will measure the frequency of the incoming clock by comparison with the audio x-tal clock (typically 16.93 mhz). multiplexer (1) selects the incoming clock source. registers (2) , (3) , and xor (4) are an edge detector. multiplexer (5) is a by-pass for the iec958 input. the rest of the circuit is a second-order filter with a bandwidth of approximately 80 hz. the output freqmeas(31:0) is an unsigned number, giving the frequency of the selected source in function of the x-tal clock. the filter is calculated internally in 48 bit precision. the 16 lsbs are not sent out. the value read from the freqmeas register is calculates as follows: for measurement on iis: freqmeas = (iis sclk freq * 2)/faudio * (2 ** 15) * gain for measurement on ebu: freqmeas = (ebu freq) / faudio * (2 ** 15) * gain table 17-37 phaseconfig and frequency measure register addresses address name width description reset value access mbar2 + bas 0xa8:0xab freqmeas 32 frequency measurement r xor 1 d d d d 2 3 4 5 6 + 7 8 910 11 + 12 13 14 15 16 sat sat freqmeas[31:0] 16.93 mhz sclk1 sclk2 sclk3 ebu-in select phase/frequency determination and xtrim function motorola section 17 audio functions 17-39 table 17-38 phaseconfig register bits 7 6 5 4 3 2 1 0 field gain select source select reset 000000 r/w r/w r/w r/w r/w r/w r/w r/w r/w addr mbar2 + 0xa3 table 17-39 phaseconfig bit descriptions bit name description gain select 000: 6 * 2 ** 15 001: 4 * 2 ** 15 010: 3 * 2 ** 15 011: 4 * 2 ** 14 100: 3 * 2 ** 14 101: 4 * 2 ** 13 110: 3 * 2 ** 13 source select 000: sclk1 001: sclk2 010: sclk3 011: sclk4 100: ebuin others: reserved, undefined table 17-40 phaseconfig register description (0xa0) field field name description reset 5:3 gain select 000: 6 * 2 ** 15 001: 4 * 2 ** 15 010: 3 * 2 ** 15 011: 4 * 2 ** 14 100: 3 * 2 ** 14 101: 4 * 2 ** 13 110: 3 * 2 ** 13 000 2:0 source select 000: sclk1 001: sclk2 010: sclk3 011: sclk4 100: ebuin others: reserved, undefined 000 17-40 mcf5249um motorola phase/frequency determination and xtrim function 17.6.1.1 filtering for the discrete time oscillator the frequency measurement circuit first detects the edges of the incoming clock. this pulse signal is then passed through an 80 hz band-width low-pass filter. the signal that comes after the low-pass filter is low-noise, and is suitable for precision frequency measurement. (expected noise level: order-of magnitude -100 db). before it can be used as a frequency increment for the discrete time oscillator, it must undergo additional filtering to push back the noise level on the phase. 17.6.2 xtrim option - locking xt al clock to incoming signal the xtrim output allows use of varicap-controlled crystal. (see figure 17-12 ). to do this, the xtrim must output a pwm/pdm modulated phase-error signal. one 16-bit config register is associated with this functionality. figure 17-12 xtrim external circuit the duty cycle output on xtrim is proportional to the value written to register xtrim. 0x0000 corresponds with duty cycle 0, 0xffff corresponds with 100%. 0x8000 corresponds with 50%. 17.6.3 xtrim internal logic for xtrim, the internal circuit of the pdm modulator is used as shown in figure 17-13 . it is a first-order pulse density modulator, working from the system clock divided by 16. table 17-41 xtrim register address and description address name width description reset value access mbar2 + bas 0xa6:0xa7 xtrim 16 xtrim output value 0x8000 rw mcf5249 device crin crout xtrim 16.98 mhz 1n 1n 2x100k 100k audio interface memory map motorola section 17 audio functions 17-41 figure 17-13 pdm modulator used on xtrim output 17.7 audio interface memory map all of the audio interface registers listed in the following table have already been shown in the various parts of this section. they are repeated here as a quick reference. table 17-42 audio interface memory map address access size bits name description mbar2 + 0x12 rw 32 iis1config config register for iis interface 1 mbar2 + 0x16 rw 32 iis2config config register for iis interface 2 mbar2 + 0x1a rw 32 iis3config config register for iis interface 3 mbar2 + 0x1e rw 32 iis4config config register for iis interface 4 mbar2 + 0x20 rw 32 ebu1config config register for ebu 1 interface mbar2 + 0x20 rw 32 ebu2config config register for ebu 2 interface mbar2 + 0x24:0x27 r 32 ebu1rcvcchannel control channel 1 as received by ebu interface - first 32 bits mbar2 + 0xd0:0xd3 r 32 ebu2rcvcchannel control channel 2 as received by ebu interface - first 32 bits mbar2 + 0x28:0x2b rw 32 ebu1txcchannel ?c? channel bits for ebu transmitter - consumer format mbar2 + 0x2c:0x2f rw 32 ebu2txcchannel ?c? channel bits fro ebu transmitter - professional format mbar2 + 0x32 rw 16 dataincontrol pdir source select sysclock/16 reg e d 1 2 3 xtrim output 16-bit adder pdmout[15:0] memory-mapped register 17-42 mcf5249um motorola audio interface memory map mbar2 bas + 0x34:0x37 mbar2 bas + 0x38:0x3b mbar2 bas + 0x3c:0x3f mbar2 bas + 0x40:0x43 r 32 pdir1-l processor data in - left multiple read addresses allow movem instruction to read fifo mbar2 bas + 0x44:0x47 mbar2 bas + 0x48:0x4b mbar2 bas + 0x4c:0x4f mbar2 bas + 0x50:0x53 r 32 pdir3-l processor data in - left multiple read addresses allow movem instruction to read fifo mbar2 bas + 0x54:0x57 mbar2 bas + 0x58:0x5b mbar2 bas + 0x5c:0x5f mbar2 bas + 0x60:0x63 r 32 pdir1-r processor data in - right mbar2 bas + 0x64:0x67 mbar2 bas + 0x68:0x6b mbar2 bas + 0x6c:0x6f mbar2 bas + 0x70:0x73 pdir3-r processor data in - right mbar2 bas + 0x34:0x37 mbar2 bas + 0x38:0x3b mbar2 bas + 0x3c:0x3f mbar2 bas + 0x40:0x43 w 32 pdor1-l processor data out 1 - left mbar2 bas + 0x44:0x47 mbar2 bas + 0x48:0x4b mbar2 bas + 0x4c:0x4f mbar2 bas + 0x50:0x53 w 32 pdor1-r processor data out 1 - right mbar2 bas + 0x54:0x57 mbar2 bas + 0x58:0x5b mbar2 bas + 0x5c:0x5f mbar2 bas + 0x60:0x63 w 32 pdor2-l processor data out 2 - left mbar2 bas + 0x64:0x67 mbar2 bas + 0x68:0x6b mbar2 bas + 0x6c:0x6f mbar2 bas + 0x70:0x73 w 32 pdor2-r processor data out 2 - right mbar2 bas + 0x74:0x77 mbar2 bas + 0x78:0x7b mbar2 bas + 0x7c:0x7f mbar2 bas + 0x80:0x83 w 32 pdor3 processor data out 3 left + right mbar2 bas + 0x74:0x77 mbar2 bas + 0x78:0x7b mbar2 bas + 0x7c:0x7f mbar2 bas + 0x80:0x83 r 32 pdir2 processor data in 2 left + right mbar2 bas + 0x84:0x87 rw 32 uchanneltransmit u channel transmit register mbar2 + 0x88 r 32 uchannelreceive u channel receive register mbar2 + 0x8c r 32 qchannelreceive q channel receive register mbar2 bas +0x92:0x93 rw 16 cdtextcontrol cd text configuration register mbar2 + 0x9f rw 8 dmaconfig configure dma table 17-42 audio interface memory map address access size bits name description audio interface memory map motorola section 17 audio functions 17-43 mbar2 + 0xa2 rw 8 phaseconfig configure phase measurement circuit mbar2 + bas 0xa6:0xa7 rw 16 xtrim value output on xtrim pin mbar2 bas + 0xa8:0xab r 32 freqmeas phase /frequency measurement mbar2 + 0xc8 rw 32 blockcontrol block decoder/encoder control mbar2 + 0xce rw 16 audioglob fifo sync mechanism, audiotick interrupt table 17-42 audio interface memory map address access size bits name description 17-44 mcf5249um motorola audio interface memory map motorola section 18 i 2 c modules 18-1 section 18 i 2 c modules 18.1 i 2 c overview the mcf5249 provides dual i 2 c interface capability. this bus was formerly referred to as the motorola bus (mbus). the i 2 c interface described in this section is fully compatible with the i 2 c bus standard. note: the second i 2 c module pins are muxed with the qspi module. select the i 2 c function for these pins using the pllcr register. the i 2 c is a two-wire, bidirectional serial bus that provides a simple and efficient method of data exchange between devices. this two-wire bus minimizes the interconnection between devices. the i 2 c bus is suitable for applications requiring occasional communications over a short distance between many devices. the flexible i 2 c allows additional devices to be connected to the bus for expansion and system development. the interface operates up to 100 kbps with maximum bus loading and timing. the i 2 c system is a true multimaster bus including collision detection and arbitration that prevents data corruption if two or more masters attempt to control the bus simultaneously. this feature allows for complex applications with multiprocessor control. it can also be used for rapid testing and alignment of end products using external connections to an assembly line computer. 18.2 i 2 c interface features compatibility with i 2 c bus standard multimaster operation software-programmable for one of 64 different serial clock frequencies software-selectable acknowledge bit interrupt-driven byte-by-byte data transfer arbitration-lost interrupt with automatic mode switching from master to slave calling address identification interrupt start and stop signal generation/detection repeated start signal generation acknowledge bit generation/detection bus-busy detection figure 18-1 shows a block diagram of the i 2 c module. 18-2 mcf5249um motorola i2c system configuration 18.3 i 2 c system configuration i 2 c module uses a serial data line (sda) and a serial clock line (scl) for data transfer. all devices connected to these two signals must have open drain or open collector outputs. the logic and function is exercised on both lines with external pullup resistors. the default state of i 2 c is as a slave receiver out of reset. thus, when not programmed to be a master or responding to a slave transmit address, the i 2 c module should always return to the default state of slave receiver (check section 18.6.1 initialization sequence for exceptions). note: this i 2 c module is designed to be compatible with the i 2 c bus protocol from philips. for further information on i 2 c system configuration, protocol, and restrictions please refer to the philips i 2 c standard figure 18-1 i 2 c module block diagram address compare in/out data shift register start, stop, and arbitration control input sync clock control registers and coldfire interface addr_decode ctrl_reg freq_reg addr_reg status_reg data_reg data_mux sda scl addr irq data i2c protocol motorola section 18 i 2 c modules 18-3 18.4 i 2 c protocol a standard communication is composed of four parts: 1. start signal 2. slave address transmission 3. data transfer 4. stop signal they are described briefly in the following sections and shown in figure 18-2 . figure 18-2 i 2 c standard communication protocol 18.4.1 start signal when the bus is free, i.e., no master device is engaging the bus (both scl and sda lines are at logic high), a master can initiate communication by sending a start signal. as shown in figure 18-2 , a start signal is defined as a high-to-low transition of sda while scl is high. this signal denotes the beginning of a new data transfer (each data transfer can contain several bytes of data) and awakens all slaves. 18.4.2 slave address transmission the first byte of data transferred by the master immediately after the start signal is the slave address. this is a seven-bit calling address followed by a r/w bit. the r/w bit tells the slave data transfer direction. no two slaves in the system can have the same address. in addition, if the i 2 c is master, it must not transmit an address that is equal to its slave address. the i 2 c cannot be master and slave at the same time. only the slave with an address that matches the one transmitted by the master will respond. it returns an acknowledge bit by pulling the sda low at the 9th clock (see figure 18-2 ). 12345678 12345678 scl 1234567 8 12 5 678 34 9 9 ad7 ad6 ad5 ad4 ad3 ad2 ad1 r/w xxx d7 d6 d5 d4 d3 d2 d1 d0 ad7 ad6 ad5 ad4 ad3 ad2 ad1 r/w ad7 ad6 ad5 ad4 ad3 ad2 ad1 r/w 99 xx new calling address r/w no ack bit stop signal repeated start signal ack bit r/w calling address start signal sda msb lsb start signal calling address r/w ack bit msb lsb data byte no ack bit stop signal lsb msb lsb msb sda scl 18-4 mcf5249um motorola i2c protocol 18.4.3 data transfer once successful slave addressing is achieved, the data transfer can proceed on a byte-by-byte basis in the direction specified by the r/w bit sent by the calling master. each data byte is 8 bits long. data can be changed only while scl is low and must be held stable while scl is high, as shown in figure 18-2 . there is one clock pulse on scl for each data bit with the msb being transferred first. each byte of data must be followed by an acknowledge bit, which is signalled from the receiving device by pulling the sda low at the ninth clock. one complete data byte transfer needs nine clock pulses. if the slave receiver does not acknowledge the master, the sda line must be left high by the slave. the master can then generate a stop signal to abort the data transfer or a start signal (repeated start) to start a new calling sequence. if the master receiver does not acknowledge the slave transmitter after a byte transmission, it means ?end of data'? to the slave. the slave releases the sda line for the master to generate a stop or start signal. 18.4.4 repeated start signal as shown in figure 18-2 , a repeated start signal is a start signal generated without first generating a stop signal to terminate the communication. the master uses this method to communicate with another slave or with the same slave in a different mode (transmit/receive mode) without releasing the bus. 18.4.5 stop signal the master can terminate the communication by generating a stop signal to free the bus. however, the master can generate a start signal followed by a calling command without generating a stop signal first. this is called repeated start. a stop signal is defined as a low-to-high transition of sda while scl is at logical 1 (see figure 18-2 ). note: a master can generate a stop even if the slave has made an acknowledgment at which point the slave must release the bus. 18.4.6 arbitration procedure i 2 c is a true multimaster bus that allows connection to more than one master. if two or more masters try to simultaneously control the bus, a clock synchronization procedure determines the bus clock, for which the low period is equal to the longest clock low period and the high is equal to the shortest one among the devices. a data arbitration procedure determines the relative priority of the contending masters. a bus master loses arbitration if it transmits logic 1 while another master transmits logic 0. the losing masters immediately switch over to slave-receive mode and stop driving sda output. in this case, the transition from master to slave mode does not generate a stop condition. meanwhile, hardware sets mbsr[ial] to indicate loss of arbitration. 18.4.7 clock synchronization because wire-and logic is performed on scl line, a high-to-low transition on scl line affects all the devices connected on the bus. the devices start counting their low period when the master drives the scl line low. once a device clock has gone low, it holds the scl line low until the clock high state is reached. however, the change of low to high in the mcf5249 clock may not change the state of the scl line if another device clock is still within its low period. therefore, synchronized clock scl is held low by the device with the longest low period. devices with shorter low periods enter a high wait state during this time (see figure 18-3 ). when all devices concerned have counted off their low period, the synchronized clock programming model motorola section 18 i 2 c modules 18-5 scl line is released and pulled high. at this point, there is no difference between the device clocks and the state of the scl line and all the devices start counting their high periods. the first device to complete its high period pulls the scl line low again. figure 18-3 synchronized clock scl 18.4.8 handshaking the clock synchronization mechanism can be used as a handshake in data transfer. slave devices can hold the scl line low after completion of one byte transfer (9 bits). in such cases, it halts the bus clock and forces the master clock into wait states until the slave releases the scl line. 18.4.9 clock stretching slaves can use the clock synchronization mechanism to slow down the transfer bit rate. after the master has driven scl low, the slave can drive scl low for the required period and then release it. if the slave scl low period is greater than the master scl low period, the resulting scl bus signal low period is stretched. 18.5 programming model internal configuration of the five registers used in the i 2 c interface are detailed in the following subsections. table 18-1 shows the programmer?s model of the i 2 c interface. table 18-1 i 2 c interfaces programmer?s model address i 2 c module registers mbar+$280 i 2 c address register (madr) mbar+$284 i 2 c frequency divider register (mfdr) mbar+$288 i 2 c control register (mbcr) internal counter reset scl1 scl2 scl wait start counting high period 18-6 mcf5249um motorola programming model note: external masters cannot access the mcf5249 on-chip memories or mbar, but can access any i 2 c module register. 18.5.1 i 2 c address registers (madr) this register contains the address that the i 2 c will respond to when addressed as a slave. note: it is not the address sent on the bus during the address transfer. 18.5.2 i 2 c frequency divider registers (mfdr) the mfdr provides a programmable prescalar to configure the clock for bit rate selection. mbar+$28c i 2 c status register (mbsr) mbar+$290 i 2 c data i/o register (mbdr) mbar2 + $440 mbar2 i 2 c address register (madr2) mbar2 + $444 mbar2 i 2 c frequency divider register (mfdr2) mbar2 + $448 mbar2 i 2 c control register (mbcr2) mbar2 + $44c mbar2 i 2 c status register (mbsr2) mbar2 + $450 mbar2 i 2 c data i/o register (mbdr2) table 18-2 madr register bits 7 6 5 4 3 2 1 0 field adr7 adr6 adr5 adr4 adr3 adr2 adr1 - reset00000000 r/w read/write supervisor or user mode addr mbar+$280 (madr) mbar2+$440 (madr2) table 18-3 madr bit descriptions bit name description adr7?adr1 ? slave address bit 1 to bit 7 contain the specific slave address to be used by the i 2 c module. slave mode is the default i 2 c mode for an address match on the bus. table 18-1 i 2 c interfaces programmer?s model address i 2 c module registers programming model motorola section 18 i 2 c modules 18-7 table 18-4 mfdr register bits 7 6 5 4 3 2 1 0 field - - ic5 ic4 ic3 ic2 ic1 ic0 reset00000000 r/w read/write supervisor or user mode addr mbar+ $284 (mfdr) mbar2+ $444 (mfdr2) table 18-5 mfdr bit descriptions bit name description ic5?ic0 ?i 2 c clock rate 5?0 this field is used to prescale the clock for bit rate selection. due to the potential slow rise and fall times of the scl and sda signals, bus signals are sampled at the prescaler frequency. the serial bit clock frequency is equal to the system clock divided by the divider shown in table 18-6 (in previous implementations of the i 2 c (e.g., mc68307), the ibc[5] (ic[5]) bit was not implemented. clearing this bit in software maintains complete compatibility with such products.) note: the mfdr frequency value can be changed at any point in a program. table 18-6 i 2 c prescaler values mbc5-0 (hex) divider (dec) mbc5-0 (hex) divider (dec) 00 28 20 20 01 30 21 22 02 34 22 24 03 40 23 26 04 44 24 28 05 48 25 32 06 56 26 36 07 68 27 40 08 80 28 48 09 88 29 56 0a 104 2a 64 0b 128 2b 72 0c 144 2c 80 0d 160 2d 96 0e 192 2e 112 0f 240 2f 128 10 288 30 160 11 320 31 192 12 384 32 224 18-8 mcf5249um motorola programming model 18.5.3 i 2 c control registers (mbcr) the mbcr enable the i 2 c module and the i 2 c interrupt. it also contains the bits that govern operation as master or slave. 13 480 33 256 14 576 34 320 15 640 35 384 16 768 36 448 17 960 37 512 18 1152 38 640 19 1280 39 768 1a 1536 3a 896 1b 1920 3b 1024 1c 2304 3c 1280 1d 2560 3d 1536 1e 3072 3e 1792 1f 3840 3f 2048 table 18-7 mbcr register bits 7 6 5 4 3 2 1 0 field ien iien msta mtx txak rsta - reset00000000 r/w read/write supervisor or user mode addr mbar+ $288 (mbcr) mbar2+ $448 (mbcr2) table 18-6 i 2 c prescaler values (continued) mbc5-0 (hex) divider (dec) mbc5-0 (hex) divider (dec) programming model motorola section 18 i 2 c modules 18-9 table 18-8 mbcr bit descriptions bit name description ien the i 2 c enable bit controls the software reset of the entire i 2 c module. 1 = the i 2 c module is enabled. this bit must be set before any other mbcr bits have any effect. 0 = the module is disabled, but registers can still be accessed. if the i 2 c module is enabled in the middle of a byte transfer, the interface behaves as follows: the slave mode ignores the current transfer on the bus and starts operating whenever a subsequent start condition is detected. master mode will not be aware that the bus is busy; therefore, if a start cycle is initiated, the current bus cycle can become corrupt. this ultimately results in either the current bus master or the i 2 c module losing arbitration, after which bus operation returns to normal. iien i 2 c interrupt enable 1 = interrupts from the i 2 c module are enabled. an i 2 c interrupt occurs provided the iif bit in the status register is also set. 0 = interrupts from the i 2 c module are disabled. this does not clear any currently pending interrupt condition. msta at reset, the master/slave mode select bit is cleared. when this bit is changed from 0 to 1, a start signal is generated on the bus, and the master mode is selected. when this bit is changed from 1 to 0, a stop signal is generated and the operation mode changes from master to slave. msta is cleared without generating a stop signal when the master loses arbitration. 1 = master mode 0 = slave mode mtx the transmit/receive mode select bit selects the direction of master and slave transfers. when addressed as a slave this bit should be set by software according to the srw bit in the status register. in master mode, this bit should be set according to the type of transfer required. therefore, for address cycles, this bit will always be high. 1 = transmit 0 = receive txak the transmit acknowledge enable bit specifies the value driven onto sda during acknowledge cycles for both master and slave receivers. writing this bit only applies when the i 2 c bus is a receiver, not a transmitter. 1 = no acknowledge signal response is sent (i.e., acknowledge bit = 1) 0 = an acknowledge signal will be sent out to the bus at the 9th clock bit after receiving one byte data rsta writing a 1 to the repeat start bit will generate a repeated start condition on the bus, provided it is the current bus master. this bit will always be read as a low. attempting a repeated start at the wrong time, if the bus is owned by another master, will result in loss of arbitration. 1 = generate repeat start cycle 0 = no repeat start 18-10 mcf5249um motorola programming model 18.5.4 i 2 c status registers (mbsr) this status register is read-only with the exception of bit 1 (iif) and bit 4 (ial), which can be cleared by software. all bits are cleared on reset except bit 7 (icf) and bit 0 (rxak), which are set (=1) at reset. table 18-9 mbsr register bits 7 6 5 4 3 2 1 0 field icf iaas ibb ial - srw iif rxak reset10000001 r/w read/write supervisor or user mode addr mbar+ $28c (mbsr) mbar2+ $44c (mbsr2) table 18-10 mbsr bit descriptions bit name description icf while one byte of data is being transferred, the data transferring bit bit is cleared. it is set by the falling edge of the 9th clock of a byte transfer. 1 = transfer complete 0 = transfer in progress iaas when its own specific address (i 2 c address register) is matched with the calling address, the addressed as a slave bit is set. the cpu is interrupted provided the iien is set. next, the cpu must check the srw bit and set its tx/rx mode accordingly. writing to the i 2 c control register clears this bit. 1 = addressed as a slave 0 = not addressed ibb the bus busy bit indicates the status of the bus. when a start signal is detected, the ibb is set. if a stop signal is detected, it is cleared. 1 = bus is busy 0 = bus is idle ial hardware sets the arbitration lost bit (ial) wh en the arbitration procedure is lost. arbitration is lost in the following circumstances: sda sampled as low when the master drives a high during an address or data-transmit cycle. sda sampled as a low when the master drives a high during the acknowledge bit of a data-receive cycle. a start cycle is attempted when the bus is busy. a repeated start cycle is requested in slave mode. a stop condition is detected when the master did not request it. this bit must be cleared by software by writing a zero to it. programming model motorola section 18 i 2 c modules 18-11 18.5.5 i 2 c data i/o registers (mbdr) when an address and r/w bit is written to the mbdr and the i 2 c is the master, a transmission will start. when data is written to the mbdr, a data transfer is initiated. the most significant bit is sent first in both cases. in the master-receive mode, reading the mbdr register allows the read to occur but also initiates next byte data receiving. in slave mode, the same function is available after it is addressed. srw when iaas is set, the slave read/write bit indicates the value of the r/w command bit of the calling address sent from the master. this bit is valid only when: a complete transfer has occurred and no other transfers have been initiated. i 2 c is a slave and has an address match. checking this bit, the cpu can select slave transmit/receive mode according to the command of the master. 1 = slave transmit, master reading from slave 0 = slave receive, master writing to slave iif the i 2 c interrupt (iif) bit is set when an interrupt is pending, which will cause a processor interrupt request (provided iien is set). iif is set when one of the following events occurs: complete one byte transfer (set at the falling edge of the 9th clock) receive a calling address that matches its own specific address in slave-receive mode arbitration lost this bit must be cleared by software by writing a zero to it in the interrupt routine. rxak the value of sda during the acknowledge bit of a bus cycle. if the received acknowledge bit (rxak) is low, it indicates an acknowledge signal has been received after the completion of 8 bits data transmission on the bus. if rxak is high, it means no acknowledge signal has been detected at the 9th clock. 1 = no acknowledge received 0 = acknowledge received table 18-11 mbdr register bits 7 6 5 4 3 2 1 0 fieldd7d6d5d4d3d2d1d0 reset00000000 r/w read/write supervisor or user mode addr mbar+$290 (mbdr) mbar2+$450 (mbdr2) table 18-10 mbsr bit descriptions bit name description 18-12 mcf5249um motorola i2c programming examples 18.6 i 2 c programming examples 18.6.1 initialization sequence a reset places the i 2 c control register into default status. before the interface can transfer serial data, users must perform an initialization procedure as follows: 1. update the frequency divider register (mfdr) and select the required division ratio to obtain scl frequency from the system bus clock. 2. update the i 2 c address register (madr) to define its slave address. 3. set the ien bit of the i 2 c control register (mbcr) to enable the i 2 c bus interface system. 4. modify the mbcr to select master/slave mode, transmit/receive mode, and interrupt-enable or not. note: during the initialization of the i 2 c bus module, the user should check the ibb bit of the mbsr register. if the ibb bit is set when the i 2 c module is enabled, then the following code sequence should be executed before proceeding with the normal initialization code. this issues a stop command to the slave device, which places it into the idle state as if it were recently power cycled. mbcr = $0 mbcr = $a0 dummy read of mbdr mbsr = $0 mbcr = $0 18.6.2 generation of start after completion of the initialization procedure, users can transmit serial data by selecting the ?master transmitter'? mode. if the mcf5249 is connected to a multimaster bus system, users must test the state of the i 2 c busy bit (ibb) to check whether the serial bus is free. if the bus is free (ibb=0), the start condition and the first byte (the slave address) can be sent. the data written to the data register comprises the address of the desired slave and the lsb is set to indicate the direction of transfer required. the bus free time (i.e., the time between a stop condition and the following start condition) is built into the hardware that generates the start cycle. depending on the relative frequencies of the system clock and the scl period, users may have to wait until the i 2 c is busy after writing the calling address to the mbdr before proceeding with the following instructions. an example of a program that generates the start signal and transmits the first byte of data (slave address) is shown as follows: chflag move.b mbsr,-(a7);check the mbb bit of the mbsr btst.b #5, (a7)+ bne.s chflag;if it is set, wait until it is clear txstart move.bmbcr,-(a7);set transmit mode bset.b #4,(a7) move.b (a7)+, mbcr move.b mbcr, -(a7);set master mode bset.b #5, (a7);generate start condition i2c programming examples motorola section 18 i 2 c modules 18-13 move.b (a7)+, mbcr; move.b calling,-(a7);transmit the calling address, d0=r/w move.b (a7)+, mbdr; ifree move.b mbsr,-(a7);check the ibb bit of the mbsr. ;if it is clear, wait until it is set. btst.b #5, (a7)+; beq.s ibfree; 18.6.3 post-transfer software response transmission or reception of a byte will set the data transferring bit (icf) to 1, which indicates one byte communication is finished. the interrupt bit (iif) is also set. an interrupt will be generated if the interrupt function is enabled during initialization by setting the iien bit. software must clear the iif bit in the interrupt routine first. the icf bit will be cleared by reading from the i 2 c data i/o register (mbdr) in receive mode or writing to mbdr in transmit mode. software can service the i 2 c i/o in the main program by monitoring the iif bit if the interrupt function is disabled. polling should monitor the iif bit rather than the icf bit because that operation is different when arbitration is lost. when an interrupt occurs at the end of the address cycle, the master will always be in transmit mode. for example, the address is transmitted. if master receive mode is required, indicated by mbdr[r/w], then the mtx bit should be toggled. during slave-mode address cycles (iaas=1), the srw bit in the status register is read to determine the direction of the subsequent transfer and the mtx bit is programmed accordingly. for slave-mode data cycles (iaas=0), the srw bit is not valid. the mtx bit in the control register should be read to determine the direction of the current transfer. the following is an example of a software response by a ?master transmitter?' in the interrupt routine (see figure 18-4 ). mbsr lea.l mbsr,-(a7);load effective address bclr.b #1,(a7)+;clear the iif flag move.b mbcr,-(a7);push the address on stack, btst.b #5,(a7)+;check the msta flag beq.s slave;branch if slave mode move.b mbcr,-(a7);push the address on stack btst.b #4,(a7)+;check the mode flag beq.s receive;branch if in receive mode move.b mbsr,-(a7);push the address on stack, btst.b #0,(a7)+;check ack from receiver bne.b end;if no ack, end of transmission transmit move.b databuf,-(a7);stack data byte move.b (a7)+, mbdr);transmit next byte of data generation of stop a data transfer ends with a stop signal generated by the ?maste r?' device. a master transmitter can generate a stop signal after all the data has been transmitted. the following code is an example showing how a master transmitter generates a stop condition. mastx move.b mbsr, -(a7); if no ack, branch to end 18-14 mcf5249um motorola i2c programming examples btst.b #0,(a7)+ bne.b end move.b txcnt,d0;get value from the transmitting counter beq.s end;if no more data, branch to end move.b databuf,-(a7);transmit next byte of data move.b (a7)+,mbdr move.b txcnt,d0;decrease the txcnt subq.l #1,d0 move.b d0,txcnt bra.s emastx;exit end lea.l mbcr,-(a7);generate a stop condition bclr.b #5,(a7)+ emastx rte; return from interrupt if a master receiver wants to terminate a data transfer, it must inform the slave transmitter by not acknowledging the last byte of data, which can be done by setting the transmit acknowledge bit (txak) before reading the next-to-last byte of data. before reading the last byte of data, a stop signal must first be generated. the following code is an example showing how a master receiver generates a stop signal. masr move.b rxcnt,d0;decrease rxcnt subq.l #1,d0 move.b d0,rxcnt beq.s enmasr;last byte to be read move.b rxcnt,d1;check second-to-last byte to be read extb.l d1 subi.l #1,d1; bne.s nxmar; not last one or second last lamar bset.b #3,mbcr;disable ack bra nxmar enmasr bclr.b #5,mbcr; last one, generate ?stop?signal nxmar move.b mbdr,rxbuf; read data and store rte generation of repeated start at the end of data transfer, if the master still wants to communicate on the bus, it can generate another start signal followed by another slave address without first generati ng a stop signal. a program example follows. restart move.b mbcr,-(a7); another start (restart) bset.b #2, (a7) move.b (a7)+, mbcr move.b calling,-(a7);transmit the calling address, d0=r/w- move.b calling,-(a7); move.b (a7)+, mbdr 18.6.4 slave mode in the slave interrupt service routine, the module that is addressed as slave bit (iaas), should be tested to check if a calling of its own address was received. if iaas is set, software should set the transmit/receive mode select bit (mtx bit of mbcr) according to the r/w command bit (srw). writing to the mbcr clears the iaas automatically. the only time iaas is read as set is from the interrupt at the end of the address cycle where an address match occurred; interrupts resulting from subsequent data transfers will have iaas cleared. a data transfer can now be initiated by writing information to mbdr, for slave transmits, or read from mbdr, in slave-receive mode. a dummy read of the mbdr in slave/receive mode will release scl, allowing the master to transmit data. i2c programming examples motorola section 18 i 2 c modules 18-15 in the slave transmitter routine, the received acknowledge bit (rxak) must be tested before transmitting the next byte of data. setting rxak means an ?end-of-data?' signal from the master receiver, after which it must be switched from transmitter mode to receiver mode by software. a read from mbdr then releases the scl line so that the master can generate a stop signal. 18.6.5 arbitration lost if several devices try to engage the bus at the same time, only one becomes master and the others lose arbitration. the devices that lost arbitration are immediately switched to slave receive mode by the hardware. their data output to the sda line is stopped, but scl is still generated until the end of the byte during which arbitration was lost. an interrupt occurs at the falling edge of the ninth clock of this transfer with ial=1 and msta=0. if one master tries to transmit or do a start while the bus is being engaged by another master, the hardware does the following: 1. inhibits the transmission 2. switches the msta bit from 1 to 0 without generating stop condition 3. generates an interrupt to cpu 4. sets the ial to indicate the failed attempt to engage the bus. when considering these cases, the slave service routine should test the ial first and the software should clear the ial bit if it is set. 18-16 mcf5249um motorola i2c programming examples figure 18-4 flow-chart of typical i 2 c interrupt routine clear master mode? tx/rx ? last byte transmitted ? rxak=0 ? end of addr cycle (master rx) ? write next byte to mbdr switch to rx mode dummy read from mbdr generate stop signal read data from mbdr and store set txak =1 generate stop signal 2nd last byte to be last byte to be ? arbitration lost? clear ial iaas=1 ? iaas=1 ? srw=1 ? tx/rx ? set tx mode write data to mbdr set rx mode dummy read from mbdr ack from receiver ? tx next byte read data from mbdr and store switch to rx mode dummy read from mbdr rte yn y y y y y y y y y n n n n n n n n n y tx rx rx tx (write) (read) n iif address cycle data cycle read read? clear master mode? tx/rx ? last byte transmitted ? rxak=0 ? end of addr cycle (master rx) ? write next byte to mbdr switch to rx mode dummy read from mbdr generate stop signal set txak =1 generate stop signal 2nd last byte to be last byte to be ? arbitration lost? clear ial iaas=1 ? iaas=1 ? srw=1 ? tx/rx ? set tx mode write data to mbdr set rx mode dummy read from mbdr ack from receiver ? tx next byte read data from mbdr and store switch to rx mode dummy read from mbdr rte yn y y y y y y y y y n n n n n n n n n y tx rx rx tx (write) (read) n iif address cycle data cycle read read? motorola section 19 debug support 19-1 section 19 debug support this section details the mcf5249 hardware debug support. the mcf5249 implements an enhanced debug architecture. the original design plus these enhancements is known as revision a (or rev. a). the enhanced functionality is clearly identified in this section. the rev. a enhancements are backward compatible with the original coldfire debug definition. the general topic of debug support is divided into three separate areas: 1. real-time trace support 2. background debug mode (bdm) 3. real-time debug support note: to enable debug mode, mtmod[3:0] pins must be = 0001. the logic required to support these three areas is contained in a debug module as shown in figure 19-1 . figure 19-1 processor/debug module interface 19.1 breakpoint (bkpt ) this section describes signals associated with the debug module. all coldfire debug signals are unidirectional and are related to the rising-edge of the processor core?s clock signal. 19.1.1 debug support signals the bkpt active-low input signal is used to request a manual breakpoint. its assertion causes the processor to enter a halted state after the completion of the current instruction. the halt status is reflected on the processor status (pst) pins as the value $f. 19.1.2 debug data (ddata[3:0]) these output signals display the hardware register breakpoint status as a default, or optionally, captured address and operand values. the capturing of data values is controlled by the setting of the coldfire cpu debug module high speed core trace port ddata , pst , pstclk communication port dsclk, dsi, dso control bkpt local bus 19-2 mcf5249um motorola configuration/status register (csr). additionally, execution of the wddata instruction by the processor captures operands which are displayed on ddata. these signals are updated each processor cycle. 19.1.3 development serial clock (dsclk) this input signal is synchronized internally and provides the clock for the serial communication port to the debug module. the maximum frequency is 1/5 the speed of the processor?s clock (clk). at the synchronized rising edge of dsclk, the data input on dsi is sampled, and the dso output changes state. see figure 19-3 for more information, 19.1.4 development serial input (dsi) the input signal is synchronized internally and provides the data input for the serial communication port to the debug module. 19.1.5 development serial output (dso) this signal provides serial output communication for the debug module responses. 19.1.6 processor status (pst[3:0]) these output signals report the processor status. table 19-1 shows the encoding of these signals. these outputs indicate the current status of the processor pipeline and are not related to the current bus transfer. the pst value is updated each processor cycle. motorola section 19 debug support 19-3 19.1.7 processor status clock (pstclk) since the debug trace port signals transition each processor cycle and is not related to the external bus frequency, an additional signal is output from the coldfire microprocessor. the pstclk signal is a delayed version of the processor?s high-speed clock and its rising-edge is used by the development system to sample the values on the pst and ddata output buses. the pstclk signal is intended for use in the standard 26-pin debug connector. see figure 19-26 . if the real-time trace functionality is not being used, the pcd bit of the csr may be set (csr[17] = 1) to force the pstclk, pst and ddata outputs to be quiescent. table 19-1 processor status encoding pst[3:0] definition (hex) (binary) $0 0000 continue execution $1 0001 begin execution of an instruction $2 0010 reserved $3 0011 entry into user-mode $4 0100 begin execution of pulse and wddata instructions $5 0101 begin execution of taken branch or sync_pc $6 0110 reserved $7 0111 begin execution of rte instruction $8 1000 begin 1-byte transfer on ddata $9 1001 begin 2-byte transfer on ddata $a 1010 begin 3-byte transfer on ddata $b 1011 begin 4-byte transfer on ddata $c 1100 exception processing? $d 1101 emulator-mode entry exception processing? $e 1110 processor is stopped, waiting for interrupt? $f 1111 processor is halted ? note: ?these encodings are asserted for multiple cycles. 19-4 mcf5249um motorola real-time trace support 19.2 real-time trace support in the area of debug functions, one fundamental requirement is support for real-time trace functionality. for example, definition of the dynamic execution path. the coldfire solution is to include a parallel output port providing encoded processor status and data to an external development system. this port is partitioned into two nibbles (4 bits): one nibble allows the processor to transmit information concerning the execution status of the core (processor status: pst), while the other nibble allows operand data to be displayed. (debug data : ddata). the processor status (pst) timing is synchronous with the processor status clock (pstclk) and may not be related to the current bus transfer. table 19-1 shows the encoding of these signals. the pst outputs can be used with an external image of the program to completely track the dynamic execution path of the machine when used with external development systems. the tracking of this dynamic path is complicated by any change-of-flow operation. this is especially evident when the branch target address is calculated based on the contents of a program-visible register (variant addressing.) for this reason, the ddata outputs can be configured to display the target address of these types of change-of-flow instructions. because the ddata bus is only 4 bits wide, the address is displayed a nibble at a time across multiple clock cycles. the debug module includes two 32-bit storage elements for capturing the internal coldfire bus information. these two elements effectively form a fifo buffer connecting the processor?s high-speed local bus to the external development system through the ddata signals. the fifo buffer captures branch target addresses along with certain operand data values for eventual display on the ddata output port, a nibble at a time, starting with the least-significant bit. the execution speed of the coldfire processor is affected only when both storage elements contain valid data waiting to be dumped onto the ddata port. in this case, the processor core is stalled until one fifo entry is available. in all other cases, data output on the ddata port does not impact execution speed. 19.2.1 processor status signal encoding the pst signals are encoded to reflect the state of the operand execution pipeline, and are generally not related to the current external bus transfer. 19.2.1.1 continue execution (pst = $0) many instructions complete in a single processor cycle. if an instruction requires more clock cycles, the subsequent clock cycles are indicated by driving the pst outputs with this encoding. 19.2.1.2 begin execution of an instruction (pst = $1) for most instructions, this encoding signals the first clock cycle of an instruction?s execution. certain change-of-flow opcodes, plus the pulse and wddata instructions generate different encodings. 19.2.1.3 entry into user mode (pst = $3) this encoding indicates the coldfire processor has entered user mode. this encoding is signaled after the instruction which caused the user mode entry has executed. 19.2.1.4 begin execution of pulse or wddata instructions (pst = $4) the coldfire instruction set architecture includes a pulse opcode. this opcode generates a unique pst encoding, $4, when executed. this instruction can define logic analyzer triggers for debug and/or performance analysis. additionally, a wddata instruction is supported that allows the processor core to write any operand (byte, word, longword) directly to the ddata port, independent of any debug module configuration. this opcode also generates the special pst encoding ($4) when executed, followed by the real-time trace support motorola section 19 debug support 19-5 appropriate marker and then the data transfer on the ddata outputs. the length of the data transfer is dependent on the operand size of the wddata instruction. 19.2.1.5 begin execution of taken branch (pst = $5) this encoding is generated whenever a taken branch is executed. for certain opcodes, the branch target address may be optionally displayed on ddata depending on the control parameters contained in the configuration/status register (csr). the number of bytes of the address to be displayed is also controlled in the csr and indicated by the pst marker value immediately preceding the ddata outputs. the bytes are always displayed in a least-significant to most-significant order. the processor captures only those target addresses associated with taken branches using a variant addressing mode. for example, all jmp and jsr instructions using address register indirect or indexed addressing modes, all rte and rts instructions as well as all exception vectors. the simplest example of a branch instruction using a variant address is the compiled code for a c language ?case? statement. typically, the evaluation of this statement uses the variable of an expression as an index into a table of offsets, where each offset points to a unique case within the structure. for these types of change-of-flow operations, the coldfire processor uses the debug pins to output a sequence of information on successive processor clock cycles: 1. identify a taken branch has been executed using the pst pins ($5). 2. using the pst pins, optionally signal the target address is to be displayed on the ddata pins. the encoding ($9, $a, $b) identifies the number of bytes that are displayed . 3. the new target address is optionally available on subsequent cycles using the nibble-wide ddata port. the number of bytes of the target address displayed on this port is a configurable parameter (2, 3, or 4 bytes). another example of a variant branch instruction would be a jmp (a0) instruction. figure 19-2 shows the outputs of the pst and ddata signals when a jmp (a0) instruction executed, assuming the csr is programmed to display the lower two bytes of an address. figure 19-2 example pst/ddata diagram pst is driven with a $5 indicating a taken branch. in the second cycle, pst is driven with a marker value of $9 indicating a two-byte address that is displayed four bits at a time on the ddata signals over the next four clock cycles. the remaining four clock cycles display the lower two-bytes of the address (a0), least significant nibble to most significant nibble. the output of the pst signals after the jmp instruction completes is dependent on the target instruction. the pst can continue with the next instruction before the address has completely displayed on the ddata because of the ddata fifo. if the fifo is full and the next instruction needs to display captured values on ddata, the pipeline stalls (pst = $0) until space is available in the fifo. pstclk pst ddata $5 $0 $0 $9 a[3:0] a[7:4] a[11:8] a[15:12] 19-6 mcf5249um motorola background-debug mode (bdm) 19.2.1.6 begin execution of rte instruction (pst = $7) the unique encoding is generated whenever the return-from-exception (rte) instruction is executed. 19.2.1.7 begin data transfer (pst = $8?$b) these encodings serve as markers to indicate the number of bytes to be displayed on the ddata port on subsequent clock cycles. this encoding is driven onto the pst port one processor cycle before the actual data is displayed on ddata. when pst outputs a $8/$9/$a/$b marker value, the ddata port outputs 1/2/3/4 bytes of captured data respectively on consecutive processor cycles. 19.2.1.8 exception processing (pst = $c) this encoding is displayed during normal exception processing. exceptions which enter emulation mode (debug interrupt, or optionally trace) generate a different encoding. because this encoding defines a multicycle mode, the pst outputs are driven with this value until exception processing is completed. 19.2.1.9 emulator mode exception processing (pst = $d) this encoding is displayed during emulation mode (debug interrupt, or optionally trace). because this encoding defines a multicycle mode, the pst outputs are driven with this value until exception processing is completed. 19.2.1.10 processor stopped (pst = $e) this encoding is generated as a result of the stop instruction. the coldfire processor remains in the stopped state until an interrupt occurs. because this encoding defines a multicycle mode, the pst outputs are driven with this value until the stopped mode is exited. 19.2.1.11 processor halted (pst = $f) this encoding is generated when the coldfire processor is halted (refer to section 19.3.1 cpu halt .) because this encoding defines a multicycle mode, the pst outputs are driven with this value until the processor is restarted, or reset. 19.3 background-debug mode (bdm) background debug mode (bdm) implements a low-level system debugger in the microprocessor hardware. communication with the development system is handled through a dedicated, high-speed, full-duplex serial command interface. the bdm features are as follows: coldfire implements the bdm controller in a dedicated hardware module. although some bdm operations do require the cpu to be halted (for example, cpu register accesses), other bdm commands such as memory accesses can be executed while the processor is running. the read/write control register commands, rcreg and wcreg use the register coding scheme from the movec instruction. the read/write debug module register commands, rdmreg and wdmreg support debug module register accesses. illegal command responses can be returned using the fill and dump commands, if not immediately preceded by certain, specific bdm commands. for any command performing a byte-sized memory read operation, the upper 8 bits of the response data are undefined. the referenced data is returned in the lower 8 bits of the response. the debug module forces alignment for memory-referencing operations: long accesses are forced to a 0-modulo-4 address; word accesses are forced to a 0-modulo-2 address. an address error response is never returned. background-debug mode (bdm) motorola section 19 debug support 19-7 19.3.1 cpu halt although many bdm operations can occur in parallel with cpu operation, unrestricted bdm operation requires the cpu to be halted. a number of sources can cause the cpu to halt, including the following as shown in order of priority: 1. the occurrence of the catastrophic fault-on-fault condition automatically halts the processor. 2. the occurrence of a hardware breakpoint can be configured to generate a pending halt condition in a manner similar to the assertion of the bkpt signal. in all cases, the assertion of this type of halt is first made pending in the processor. next, the processor samples for pending halt and interrupt conditions once per instruction. once the pending condition is asserted, the processor halts execution at the next sample point. see section 19.4.1 theory of operation for more detail. 3. the execution of the halt coldfire instruction immediately suspends execution. by default this is a supervisor instruction and attempted execution while in user mode generates a privilege violation exception. a user halt enable (uhe) control bit is provided in the configuration/status register (csr) to allow execution of halt in user mode. the processor may be restarted after the execution of the halt instruction by serial shifting a ?go? command into the debug module. execution continues at the instruction following the halt opcode. 4. the assertion of the bkpt input pin is treated as a pseudo-interrupt. for example, the halt condition is made pending until the processor core samples for halts/interrupts. the processor samples for these conditions once during the execution of each instruction. if there is a pending halt condition at the sample time, the processor suspends execution and enters the halted state. there are two special cases involving the assertion of the bkpt pin to be considered. after the system reset signal is negated, the processor waits for 16 clock cycles before beginning reset exception processing. if the bkpt input pin is asserted within the first eight cycles after rsti is negated, the processor enters the halt state, signaling that halt status, ($f), on the pst outputs. while in this state, all resources accessible through the debug module can be referenced. this is the only opportunity to force the coldfire processor into emulation mode using the emu bit in the configuration/status register (csr). once the system initialization is complete, the processor response to a bdm go command is dependent on the set of bdm commands performed while breakpointed. specifically, if the processor?s pc register was loaded, then the go command simply causes the processor to exit the halted state and pass control to the instruction address contained in the pc. note: in this case, the normal reset exception processing is bypassed. conversely, if the pc register was not loaded, then the go command causes the processor to exit the halted state and continue with reset exception processing. coldfire also handles a special case of the assertion of bkpt while the processor is stopped by execution of the stop instruction. for this case, the processor exits the stopped mode and enters the halted state. once halted, all bdm commands may be exercised. when the processor is restarted, it continues with the execution of the next sequential instruction. for example, the instruction following the stop opcode. the halt source is indicated in csr[27:24]. for simultaneous halt conditions, the highest priority source is indicated. 19.3.2 bdm serial interface once the cpu is halted and the halt status reflected on the pst outputs, the development system may send unrestricted commands to the debug module. the debug module implements a synchronous protocol using a three-pin interface: development serial clock (dsclk), development serial input (dsi), and development serial output (dso). the development system serves as the serial communication channel 19-8 mcf5249um motorola background-debug mode (bdm) master and is responsible for generation of the clock (dsclk). the maximum operating bandwidth of the serial channel is dc to 1/5 of the processor frequency. the channel uses a full duplex mode, where data is transmitted and received simultaneously by both master and slave devices. the transmission consists of 17-bit packets composed of a status/control bit and a 16-bit data word. as shown in figure 19-3 , all state transitions are enabled on a rising edge of the processor clock when dsclk is high. for example, dsi is sampled and dso is driven. the dsclk signal must also be sampled low (on a positive edge of cpuclk) between each bit exchange. the msb is transferred first. figure 19-3 1 bdm serial transfer both dsclk and dsi are synchronized inputs.the dsclk signal essentially acts as a pseudo ?clock enable? and is sampled on the rising edge of cpuclk as well as the dsi. the dso output is delayed from the dsclk-enabled cpuclk rising edge. all events in the debug module?s serial state machine are based on the rising edge of the microprocessor clock). 19.3.2.1 receive packet format the basic receive packet of information is 17 bits long,16 data bits plus a status bit, as shown in table 19-2 . table 19-3 describes the receive bdm packets. bit descriptions are described in table 19-4 . table 19-2 receive bdm packet 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 s data field [15:0] table 19-3 cpu-generated command responses s bit data message type 0 xxxx valid data transfer 0 $ffff status ok 1 $0000 not ready with response; try again 1 $0001 error?terminated bus cycle; data invalid 1 $ffff illegal command background-debug mode (bdm) motorola section 19 debug support 19-9 19.3.2.2 transmit packet format the basic transmit packet of information is 17 bits long,16 data bits plus a control bit, as shown in table 19-5 . 19.3.3 bdm command set coldfire supports a subset of bdm commands to provide access to new hardware features. the bdm commands must not be issued whenever the coldfire processor is accessing the debug module registers using the wdebug instruction, or the resulting behavior is undefined. 19.3.3.1 bdm command set summary the bdm command set is summarized in table 19-7 . subsequent sections contain detailed descriptions of each command. 19.3.3.2 coldfire bdm commands all coldfire family bdm commands include a 16-bit operation word followed by an optional set of one or more extension words as shown in table 19-8 . table 19-4 receive bdm bit descriptions bit name description s- status[16] the status bit indicates the status of cpu-generated messages as shown in table 19-3 . data field[15:0] the data field contains the message data to be communicated from the debug module to the development system. the response message is always a single word, with the data field encoded as shown in table 19-3 . table 19-5 transmit bdm packet 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 c data field [15:0] table 19-6 transmit bit descriptions bit name description c-control [16] the control bit (bit 16) is reserved. command and data transfers initiated by the development system should clear bit 16. data field[15:0] the data field contains the message data to be communicated from the development system to the debug module. 19-10 mcf5249um motorola background-debug mode (bdm) table 19-7 bdm command summary command mnemonic description cpu impact 1 command (hex) page read a/d register rareg/rdreg read the selected address or data register and return results through the serial interface. halted $218 {a/d, reg[2:0]} 19-13 write a/d register wareg/wdreg the data operand is written to the specified address or data register. halted $208 {a/d, reg[2:0]} 19-13 read memory location read read the data at the memory location specified by the longword address. steal $1900?byte $1940?wd $1980?long 19-14 write memory location write write the operand data to the memory location specified by the longword address. steal $1800?byte $1840?wd $1880?long 19-16 dump memory block dump used with the read command to dump large blocks of memory. an initial read is executed to set up the starting address of the block and to retrieve the first result. subsequent operands are retrieved with the dump command. steal $1d00?byte $1d40?wd $1d80?long 19-17 fill memory block fill used with the write command to fill large blocks of memory. an initial write is executed to set up the starting address of the block and to supply the first operand. subsequent operands are written with the fill command. steal $1c00?byte $1c40?word $1c80?long 19-18 resume execution go the pipeline is flushed and refilled before execution resumes at the current pc. halted $0c00 19-20 no operation nop nop performs no operation and may be used as a null command. parallel $0000 19-20 read control register rcreg read the system control register. halted $2980 19-21 write control register wcreg write the operand data to the system control register. halted $2880 19-22 read debug module register rdmreg read the debug module register. parallel $2d {$4? drc[4:0]} 19-22 write debug module register wdmreg write the operand data to the debug module register. parallel $2c {$4? drc[4:0]} 19-23 note: general command effect and/or requirements on cpu operation: halted?the cpu must be halted to perform this command steal?command generates bus cycles which can be interleaved with cpu accesses parallel?command is executed in parallel with cpu activity refer to command summaries for detailed operation descriptions. background-debug mode (bdm) motorola section 19 debug support 19-11 table 19-9 describes the bdm bit fields. 19.3.3.3 command sequence diagram a command sequence diagram (see figure 19-4 ) shows the serial bus traffic for each command. each bubble in the diagram represents a single 17-bit transfer across the bus. the top half in each bubble corresponds to the data transmitted by the development system to the debug module; the bottom half table 19-8 bdm command format 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 operation 0 r/w op size 0 0 a/d register extension word(s) table 19-9 bdm bit descriptions bit name description operation field the operation field specifies the command. r/w field the r/w field specifies the direction of operand transfer. when the bit is set, the transfer is from the cpu to the development system. when the bit is cleared, data is written to the cpu or to memory from the development system. operand size for sized operations, this field specifies the operand data size. all addresses are expressed as 32-bit absolute values. the size field is encoded as listed in table 19-10 . address / data (a/d) field the a/d field is used in commands that operate on address and data registers in the processor. it determines whether the register field specifies a data or address register. a one indicates an address register; zero, a data register. register field in commands that operate on processor registers, this field specifies which register is selected. the field value contains the register number. extension word(s) (as required) certain commands require extension words for addresses and/or immediate data. addresses require two extension words because only absolute long addressing is permitted. immediate data can be either one or two words in length?byte and word data each require a single extension word; longword data requires two words. both operands and addresses are transferred most significant word first. in the following descriptions of the bdm command set, the optional set of extension words is defined as ?address,? ?data,? or ?operand data.? table 19-10 bdm size field encoding encoding operand size bit values 00 byte 8 bits 01 word 16 bits 10 longword 32 bits 11 reserved 19-12 mcf5249um motorola background-debug mode (bdm) corresponds to the data returned by the debug module in response to the previous development system commands. command and result transactions are overlapped to minimize latency. figure 19-4 command sequence diagram the cycle in which the command is issued contains the development system command mnemonic (in this example, ?read memory location?). during the same cycle, the debug module responds with either the low-order results of the previous command or a command complete status (if no results were required). during the second cycle, the development system supplies the high-order 16 bits of the memory address. the debug module returns a ?not ready? response unless the received command was decoded as unimplemented, in which case the response data is the illegal command encoding. if an illegal command response occurs, the development system should retransmit the command. note: the ?not ready? response can be ignored unless a memory-referencing cycle is in progress. otherwise, the debug module can accept a new serial transfer after 32 processor clock periods. in the third cycle, the development system supplies the low-order 16 bits of a memory address. the debug module always returns the ?not ready? response in this cycle. at the completion of the third cycle, the debug module initiates a memory read operation. any serial transfers that begin while the memory access is in progress return the ?not ready? response. results are returned in the two serial transfer cycles following the completion of the memory access. the data transmitted to the debug module during the final transfer is the opcode for the following command. if a memory or register access is terminated with a bus error, the error status (s=1, data=$0001) is returned in place of the result data. next cmd read memory location ?not ready? next cmd ls result berr xxx ?not ready? next cmd ?not ready? ls addr ?not ready? xxx ?illegal? ms addr ?not ready? read (long) ??? commands transmitted to the debug module command code transmitted during this cycle responses from the debug module results from previous command xxx ms result xxx high-order 16 bits of memory address low-order 16 bits of memory address non-serial related activity sequence taken if operation has not completed next mode command data unused from this transfer sequence taken if illegal command is received by debug module sequence taken if bus error occurs on memory access high and low-order 16 bits of results background-debug mode (bdm) motorola section 19 debug support 19-13 19.3.3.4 command set descriptions the bdm command set is summarized in table 19-7 . subsequent sections contain detailed descriptions of each command. note: the bdm status bit (s) is zero for normally-completed commands, while illegal commands, ?not ready? responses and bus-error transfers return a logic one in the s bit. refer to section 19.3.2 bdm serial interface for information on the serial packet receive packet format unassigned command opcodes are reserved by motorola for future expansion. all unused command formats within any revision level perform a nop and return the illegal command response. 19.3.3.4.1 read address/data register (rareg/rdreg) rareg and rdreg reads the selected address or data register and return the 32-bit result. a bus error response is returned if the cpu core is not halted. figure 19-5 command/result formats command sequence: figure 19-6 read a/d register command sequence ?operand data? none ?result data? the contents of the selected register are returned as a longword value. the data is returned most significant word first. 19.3.3.4.2 write address/data register (wareg and wdreg) wareg and wdreg write the operand longword data to the specified address or data register. all 32 register bits are altered by the write. a bus error response is returned if the cpu core is not halted. next cmd ?not ready? next cmd ls result berr rareg/rdreg ??? xxx ms result xxx 19-14 mcf5249um motorola background-debug mode (bdm) command format: command sequence: figure 19-7 write a/d register command sequence operand data longword data is written into the specified address or data register. the data is supplied most significant word first. result data command complete status is indicated by returning the data $ffff (with the status bit cleared) when the register write is complete. 19.3.3.4.3 read memory location (read) the read command reads the operand data from the memory location specified by the longword address. the address space is defined by the contents of the low-order 5 bits {tt, tm} of the bdm address attribute register (baar). the hardware forces the low-order bits of the address to zeros for word and longword accesses to ensure that operands are always accessed on natural boundaries: words on 0-modulo-2 addresses, longwords on 0-modulo-4 addresses. figure 19-8 wareg/wdreg command format table 19-11 wareg/wdreg command 1514131211109876543210 $2 $0 $8 a/d register data [31:16] data [15:0] next cmd ?not ready? ls data berr wdreg/wareg ??? ms data xxx ?not ready? ?not ready? next cmd ?cmd complete? background-debug mode (bdm) motorola section 19 debug support 19-15 figure 19-9 read command/result format command sequence: figure 19-10 read memory location command sequence ?operand data? the single operand is the longword address of the requested memory location. next cmd read memory location ?not ready? berr xxx ?not ready? ls addr ?not ready? ms addr ?not ready? read (b/w) ??? next cmd cmd complete xxx next cmd read memory location ?not ready? berr xxx ?not ready? ls addr ?not ready? ms addr ?not ready? read (long) ??? xxx xxx ms result next cmd ls result 19-16 mcf5249um motorola background-debug mode (bdm) ?result data? the requested data is returned as either a word or longword. byte data is returned in the least significant byte of a word result, with the upper byte undefined. word results return 16 bits of significant data; longword results return 32 bits. a value of $0001 (with the status bit set) is returned if a bus error occurs. 19.3.3.4.4 write memory location (write) the write command writes the operand data to the memory location specified by the longword address. the address space is defined by the contents of the low-order 5 bits {tt, tm} of the bdm address attribute register (baar). the hardware forces the low-order bits of the address to zeros for word and longword accesses to ensure that operands are always accessed on natural boundaries: words on 0-modulo-2 addresses, longwords on 0-modulo-4 addresses. command sequence: figure 19-11 write memory location command sequence write memory location berr xxx ?not ready? ls addr ?not ready? ms addr ?not ready? read (b/w) ??? next cmd result xxx data ?not ready? ?not ready? next cmd write memory location berr xxx ?not ready? ls addr ?not ready? ms addr ?not ready? write (long) ??? next cmd ?cmd complete? xxx ms data ?not ready? ?not ready? next cmd ls data ?not ready? background-debug mode (bdm) motorola section 19 debug support 19-17 operand data: two operands are required for this instruction. the first operand is a longword absolute address that specifies a location to which the operand data is to be written. the second operand is the data. byte data is transmitted as a 16-bit word, justified in the least significant byte; 16- and 32-bit operands are transmitted as 16 and 32 bits, respectively. result data: command complete status is indicated by returning the data $ffff (with the status bit cleared) when the register write is complete. a value of $0001 (with the status bit set) is returned if a bus error occurs. 19.3.3.4.5 dump memory block (dump) dump is used in conjunction with the read command to access large blocks of memory. an initial read is executed to set up the starting address of the block and to retrieve the first result. the dump command retrieves subsequent operands. the initial address is incremented by the operand size (1, 2, or 4) and saved in a temporary register. subsequent dump commands use this address, perform the memory read, increment it by the current operand size, and store the updated address in the temporary register. note: the dump command does not check for a valid address. dump is a valid command only when preceded by another dump, nop, or by a read command. otherwise, an illegal command response is returned. the nop command can be used for intercommand padding without corrupting the address pointer. the size field is examined each time a dump command is processed, allowing the operand size to be dynamically altered. figure 19-12 dump command/result format 19-18 mcf5249um motorola background-debug mode (bdm) command sequence : figure 19-13 dump memory block command sequence ?operand data?: none ?result data:? requested data is returned as either a word or longword. byte data is returned in the least significant byte of a word result. word results return 16 bits of significant data; longword results return 32 bits. a value of $0001 (with the status bit set) is returned if a bus error occurs. 19.3.3.4.6 fill memory block (fill) fill is used in conjunction with the write command to access large blocks of memory. an initial write is executed to set up the starting address of the block and to supply the first operand. the fill command writes subsequent operands. the initial address is incremented by the operand size (1, 2, or 4) and saved in a temporary register after the memory write. subsequent fill commands use this address, perform the write, increment it by the current operand size, and store the updated address in the temporary register. note: the fill command does not check for a valid address fill is a valid command only when preceded by another fill, nop or by a write command. otherwise, an illegal command response is returned. the nop command can be used for intercommand padding without corrupting the address pointer. the size field is examined each time a fill command is processed, allowing the operand size to be altered dynamically. read memory location berr xxx ?not ready? dump (b/w) ??? next cmd result xxx ?not ready? next cmd xxx ?illegal? ?not ready? next cmd read memory location berr xxx ?not ready? dump (long) ??? next cmd ms result xxx ?not ready? next cmd xxx ?illegal? ?not ready? next cmd ls result next cmd background-debug mode (bdm) motorola section 19 debug support 19-19 command formats: command sequence: figure 19-14 fill memory block command sequence table 19-12 byte fill command 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 $1 $c $0 $0 xxxxxxxx data [7:0] table 19-13 word fill command 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 $1 $c $4 $0 data [15:0] table 19-14 long fill command 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 $1 $c $8 $0 data [31:16] data [15:0] write memory location berr xxx ?not ready? fill (long) ??? next cmd ?cmd complete? xxx ?not ready? next cmd xxx ?illegal? ?not ready? next cmd ms data ?not ready? ls data ?not ready? write memory location berr xxx ?not ready? fill (b/w) ??? next cmd ?cmd complete? xxx ?not ready? next cmd xxx ?illegal? ?not ready? next cmd data ?not ready? 19-20 mcf5249um motorola background-debug mode (bdm) operand data: a single operand is data to be written to the memory location. byte data is transmitted as a 16-bit word, justified in the least significant byte; 16- and 32-bit operands are transmitted as 16 and 32 bits, respectively. result data: command complete status is indicated by returning the data $ffff (with the status bit cleared) when the register write is complete. a value of $0001 (with the status bit set) is returned if a bus error occurs. 19.3.3.4.7 resume execution (go) the go command flushes and refills the pipeline before resuming normal instruction execution. prefetching begins at the current pc and current privilege level. if any register (for example, the pc or sr) was altered by a bdm command while halted, the updated value is used as the prefetching resumes. command formats: command sequence: figure 19-15 resume execution operand data: none result data: the ?command complete? response ($0ffff) is returned during the next shift operation. 19.3.3.4.8 no operation (nop) nop performs no operation and may be used as a null command where required. command formats: command sequence: figure 19-16 no operation command sequence table 19-15 go command 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 $0 $c $0 $0 table 19-16 nop command 15 12 11 8 7 4 3 0 $0 $0 $0 $0 sync_pc go ??? next cmd ?cmd complete? sync_pc nop ??? next cmd ?cmd complete? background-debug mode (bdm) motorola section 19 debug support 19-21 ?operand data?: none ?result data?: the ?command complete? response, $ffff (with the status bit cleared), is returned during the next shift operation. 19.3.3.4.9 read control register (rcreg) rcreg reads the selected control register and returns the 32-bit result. accesses to the processor/memory control registers are always 32 bits in size, regardless of the implemented register width. the second and third words of the command effectively form a 32-bit address used by the debug module to generate a special bus cycle to access the specified control register. the 12-bit rc field is the same as that used by the movec instruction. figure 19-17 rcreg command/result formats rc encoding: rc register definition $002 cache control register (cacr) $004 access control register 0 (acr0) $005 access control register 1 (acr1) $801 vector base register (vbr) $804 mac status register (macsr) $805 mac mask register (mask) $806 mac accumulator (acc0) $807 mac accumulator (acc1) $808 mac accumulator (acc2) $80b mac accumulator (acc3) $80e status register (sr) $80f program register (pc) $c04 ram base address register (rambar0) $c05 ram base address register (rambar1) $c0f module base address register (mbar) $c0e module base address register (mbar2) 19-22 mcf5249um motorola background-debug mode (bdm) 19.3.3.4.10 write control register (wcreg) the operand (longword) data is written to the specified control register. the write alters all 32 register bits. figure 19-18 wcreg command sequence command sequence : figure 19-19 write control register command sequence operand data: two operands are required for this instruction. the first long operand selects the register to which the operand data is to be written. the second operand is the data. result data: successful write operations return a $ffff. bus errors on the write cycle are indicated by the assertion of bit 16 in the status message and by a data pattern of $0001. 19.3.3.4.11 read debug module register (rdmreg) rdmreg reads the selected debug module register and return the 32-bit result. the only valid register selection for the rdmreg command is the csr (drc = $0). write control register berr xxx ?not ready? wcreg next cmd ?cmd complete? xxx ?not ready? next cmd ms addr ?not ready? ls addr ?not ready? ??? ?not ready? ms data ?not ready? ls data background-debug mode (bdm) motorola section 19 debug support 19-23 figure 19-20 rdmreg command/result formats drc encoding: command sequence : figure 19-21 read debug module register command sequence operand data: none result data: the contents of the selected debug register are returned as a longword value. the data is returned most significant word first. 19.3.3.4.12 write debug module register (wdmreg) the operand (longword) data is written to the specified debug module register. all 32 bits of the register are altered by the write. the dsclk signal must be inactive while debug module register writes from the cpu accesses are performed using the wdebug instruction. figure 19-22 wdmreg bdm command format table 19-18 definition of drc encoding--read drc[3:0] debug register definition mnemonic initial state $0 configuration/status csr $0 $1-$f reserved - ? next cmd ?not ready? next cmd ls result ?illegal? rdmreg ??? xxx ms result xxx 19-24 mcf5249um motorola background-debug mode (bdm) drc encoding : command sequence: figure 19-23 write debug module register command sequence operand data: longword data is written into the specified debug register. the data is supplied most significant word first. result data: command complete status ($0ffff) is returned when register write is complete. 19.3.3.4.13 unassigned opcodes unassigned command opcodes are reserved by motorola. all unused command formats within any revision level perform a nop and return the illegal command response . 19.3.3.5 bdm accesses of the emac registers the presence of rounding logic in the output data path of the emac requires special care for bdm-initiated reads and writes of its programming model. in particular, any result rounding modes must be disabled during the read/write process so the exact bit-wise emac register contents are accessed. for example, a bdm read of an accumulator (ac c x) requires the following sequence: table 19-19 definition of drc encoding--write drc[3:0] debug register definition mnemonic initial state $0 configuration/status csr $0 $1-$4 reserved - ? $5 bdm address attribute baar $5 $6 bus attributes and mask aatr $5 $7 trigger definition tdr $0 $8 pc breakpoint pbr ? $9 pc breakpoint mask pbmr ? $a-$b reserved ? ? $c operand address high breakpoint abhr ? $d operand address low breakpoint ablr ? $e data breakpoint dbr ? $f data breakpoint mask dbmr ? next cmd ?not ready? ls data ?illegal? wdmreg ??? ms data xxx next cmd ?cmd complete? ?not ready? ?not ready? real-time debug support motorola section 19 debug support 19-25 bdm read accx ( rcreg macsr; // read current macsr contents & save wcreg #0,macsr; // disable all rounding modes rcreg accx; // read the desired accumulator wcreg #saved_data,macsr; // restore the original macsr ) likewise to write an accumulator register, the following bdm sequence is needed: bdm write accx ( rcreg macsr; // read current macsr contents & save wcreg #0,macsr; // disable all rounding modes wcreg #data,accx; // write the desired accumulator wcreg #saved_data,macsr; // restore the original macsr ) additionally, writes to the accumulator extension registers must be performed after the corresponding accumulators are updated because a write to any accumulator alters the corresponding extension register contents. command sequence: figure 19-24 read control register command sequence operand data: the single operand is the 32-bit rc control register select field. result data: the contents of the selected control register are returned as a longword value. the data is returned most significant word first. for those control registers with widths less than 32 bits, only the implemented portion of the register is guaranteed to be correct. the remaining bits of the longword are undefined. 19.4 real-time debug support the coldfire family provides support for the debug of real-time applications. for these types of embedded systems, the processor cannot be halted during debug, but must continue to operate. the foundation of this area of debug support is that while the processor cannot be halted to allow debugging, the system can generally tolerate small intrusions into the real-time operation. the debug module provides a number of hardware resources to support various hardware breakpoint functions. specifically, three types of breakpoints are supported: pc with mask, operand address range, and data with mask. these three basic breakpoints can be configured into one- or two-level triggers with the exact trigger response also programmable. the debug module programming model is accessible from ms addr ?not ready? ms addr ?not ready? read register xxx ?not ready? xxx ms result xxx berr next cmd ls result next cmd ?not ready? rcreg ??? control 19-26 mcf5249um motorola real-time debug support either the external development system using the serial interface or from the processor?s supervisor programming model using the wdebug instruction. 19.4.1 theory of operation the breakpoint hardware can be configured to respond to triggers in several ways. the desired response is programmed into the trigger definition register (tdr). in all situations where a breakpoint triggers, an indication is provided on the ddata output port, when not displaying captured operands or branch addresses, as shown in table 19-20 . the breakpoint status is also posted in the csr. the bdm instructions load and configure the desired breakpoints using the appropriate registers. as the system operates, a breakpoint trigger generates a response as defined in the tdr . if the system can tolerate the processor being halted, a bdm-entry can be used. with the trc bits of the tdr equal to $1, the breakpoint trigger causes the core to halt as reflected in the pst = $f status. note: for pc breakpoints, the halt occurs before the targeted instruction is executed. for address and data breakpoints, the processor may have executed several additional instructions. as a result, trigger reporting is considered imprecise. if the processor core cannot be halted, the special debug interrupt can be used. with this configuration, trc bits of the tdr equal to $2, the breakpoint trigger is converted into a debug interrupt to the processor. this interrupt is treated higher than the nonmaskable level 7 interrupt request. as with all interrupts, it is made pending until the processor reaches a sample point, which occurs once per instruction. again, the hardware forces the pc breakpoint to occur immediately (before the execution of the targeted instruction). this is possible because the pc breakpoint comparison is enabled at the same time the interrupt sampling occurs. for the address and data breakpoints, the reporting is considered imprecise because several additional instructions may be executed after the triggering address or data is seen. once the debug interrupt is recognized, the processor aborts execution and initiates exception processing. at the initiation of the exception processing, the core enters emulator mode. after the standard 8-byte exception stack is created, the processor fetches a unique exception vector, 12, from the vector table (refer to the coldfire programmer?s reference manual). execution continues at the instruction address contained in this exception vector. all interrupts are ignored while in emulator mode. users can program the debug-interrupt handler to perform the necessary context saves using the supervisor instruction set. as an example, this handler may save the state of all the program-visible registers as well as the current context into a reserved memory area. table 19-20 ddata[3:0], csr[31:28] breakpoint response ddata[3:0], csr[31:28] breakpoint status $000x no breakpoints enabled $001x waiting for level 1 breakpoint $010x level 1 breakpoint triggered $101x waiting for level 2 breakpoint $110x level 2 breakpoint triggered all other encodings are reserved for future use. real-time debug support motorola section 19 debug support 19-27 once the required operations are completed, the return-from-exception (rte) instruction is executed and the processor exits emulator mode. once the debug interrupt handler has completed its execution, the external development system can then access the reserved memory locations using the bdm commands to read memory. prior to the rev. a implementation, if a hardware breakpoint (for example, a pc trigger) is left unmodified by the debug interrupt service routine, another debug interrupt is generated after the rte instruction completes execution. in the rev. a design, the hardware has been modified to inhibit the generation of another debug interrupt during the first instruction after the rte exits emulator mode. this behavior is consistent with the existing logic involving trace mode, where the execution of the first instruction occurs before another trace exception is generated. this rev. a enhancement disables all hardware breakpoints until the first instruction after the rte has completed execution, regardless of the programmed trigger response. 19.4.1.1 emulator mode emulator mode is used to facilitate non-intrusive emulator functionality. this mode can be entered in three different ways: the emu bit in the csr may be programmed to force the coldfire processor to begin execution in emulator mode. this bit is only examined when rsti is negated and the processor begins reset exception processing. it may be set while the processor is halted before the reset exception processing begins. refer to section 19.3.1 cpu halt . a debug interrupt always enters emulation mode when the debug interrupt exception processing begins. the tcr bit in the csr may be programmed to force the processor into emulation mode when trace exception processing begins. during emulation mode, the coldfire processor exhibits the following properties: all interrupts are ignored, including level seven. if the map bit of the csr is set, all memory accesses are forced into a specially mapped address space signalled by tt = $2, tm = $5 or $6. this includes the stack frame writes and the vector fetch for the exception which forced entry into this mode. if the map bit in the csr is set, all caching of memory accesses is disabled. additionally, the sram module is disabled while in this mode. the return-from-exception (rte) instruction exits emulation mode. the processor status output port provides a unique encoding for emulator mode entry ($d) and exit ($7). 19.4.1.2 debug module hardware 19.4.1.2.1 reuse of debug module hardware (rev. a) the debug module implementation provides a common hardware structure for both bdm and breakpoint functionality. several structures are used for both bdm and breakpoint purposes. table 19-21 identifies the shared hardware structures. the shared use of these hardware structures means the loading of the register to perform any specified function is destructive to the shared function. for example, if an operand address breakpoint is loaded into the debug module, a bdm command to access memory overwrites the breakpoint. if a data breakpoint is configured, a bdm write command overwrites the breakpoint contents. 19-28 mcf5249um motorola real-time debug support 19.4.2 programming model in addition to the existing bdm commands that provide access to the processor?s registers and the memory subsystem, the debug module contains nine registers to support the required functionality. all of these registers are treated as 32-bit quantities, regardless of the actual number of bits in the implementation. the registers, known as the debug control registers, are accessed through the bdm port using two new bdm commands: wdmreg and rdmreg. these commands contain a 4-bit field, drc, which specifies the particular register being accessed. these registers are also accessible from the processor?s supervisor programming model through the execution of the wdebug instruction. thus, the breakpoint hardware within the debug module may be accessed by the external development system using the serial interface, or by the operating system running on the processor core. it is the responsibility of the software to guarantee that all accesses to these resources are serialized and logically consistent. the hardware provides a locking mechanism in the csr to allow the external development system to disable any attempted writes by the processor to the breakpoint registers (setting ipw = 1). the bdm commands must not be issued if the coldfire processor is accessing the debug module registers using the wdebug instruction. figure 19-25 debug programming mode 19.4.2.1 address breakpoint registers the address breakpoint registers (ablr and abhr) define a region in the operand address space of the processor that can be used as part of the trigger. the full 32-bits of the ablr and abhr values are compared with the address for all transfers on the processor?s high-speed local bus. the trigger definition register (tdr) determines if the trigger is the inclusive range bound by ablr and abhr, all addresses table 19-21 shared bdm/breakpoint hardware register bdm function breakpoint function aatr bus attributes for all memory commands attributes for address breakpoint abhr address for all memory commands address for address breakpoint dbr data for all bdm write commands data for data breakpoint address breakpoint registers pc breakpoint registers data breakpoint registers ablr abhr pbr pbmr dbmr dbr tdr 15 0 31 trigger definition register address attribute trigger register aatr 7 0 15 csr configuration/status register bdm address attribute register baar real-time debug support motorola section 19 debug support 19-29 outside this range, or the address in ablr only. the abhr is accessible in supervisor mode as debug control register $c using the wdebug instruction and through the bdm port using the rdmreg and wdmreg commands. the ablr is accessible in supervisor mode as debug control register $d using the wdebug instruction and through the bdm port using the wdmreg commands. the abhr is overwritten by the bdm hardware when accessing memory as described in section 19.4.1.2 debug module hardware. address[31:0]?low address this field contains the 32-bit address which marks the lower bound of the address breakpoint range. additionally, if a breakpoint on a specific address is required, the value is programmed into the ablr. address[31:0]?high address this field contains the 32-bit address which marks the upper bound of the address breakpoint range. 19.4.2.2 address attribute trigger register the aatr defines the address attributes and a mask to be matched in the trigger. the aatr value is compared with the address attribute signals from the processor?s local high-speed bus, as defined by the setting of the tdr. the aatr is accessible in supervisor mode as debug control register $6 using the wdebug instruction and through the bdm port using the wdmreg command. the lower five bits of the aatr are also used for bdm command definition to define the address space for memory references as described in section 19.4.1.2 debug module hardware. table 19-22 address breakpoint low register (ablr) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field address[31:0] reset---------------- r/w write only addr bits1514131211109876543210 field address[31:0] reset---------------- r/w write only table 19-23 address breakpoint high register (abhr) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field address[31:0] reset ---------------- r/w write only bits1514131211109876543210 field address[31:0] reset ---------------- r/w write only 19-30 mcf5249um motorola real-time debug support table 19-24 address attribute trigger register (aatr) bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field rm szm ttm tmm r sz tt tm reset 0000000000000101 r/w write only addr table 19-25 address attribute trigger bit descriptions bit name description rm[15] the read/write mask field corresponds to the r-field. setting this bit causes r to be ignored in address comparisons. szm[14:13] the size mask field corresponds to the sz field. setting a bit in this field causes the corresponding bit in sz to be ignored in address comparisons. ttm[12:11] the transfer type mask field corresponds to the tt field. setting a bit in this field causes the corresponding bit in tt to be ignored in address comparisons. tmm[10:8] the transfer modifier mask field corresponds to the tm field. setting a bit in this field causes the corresponding bit in tm to be ignored in address comparisons. r [7] the read/write field is compared with the r?w signal of the processor?s local bus. sz [6:5] the size field is compared to the size signals of the processor?s local bus. these signals indicate the data size for the bus transfer. 00 = longword 01 = byte 10 = word 11 = reserved tt [4:3] the transfer type field is compared with the transfer type signals of the processor?s local bus. these signals indicate the transfer type for the bus transfer. these signals are always encoded as if the coldfire is in the coldfire iack mode. 00 = normal processor access 01 = reserved 10 = emulator mode access 11 = acknowledge/cpu space access these bits also define the tt encoding for bdm memory commands. in this case, the 01 encoding generates an alternate master access (for backward compatibility). real-time debug support motorola section 19 debug support 19-31 19.4.2.3 program counter breakpoint register (pbr, pbmr) the pc breakpoint registers (pbr and pbmr) define a region in the code address space of the processor that can be used as part of the trigger. the pbr value is masked by the pbmr value, allowing only those bits in pbr that have a corresponding zero in pbmr to be compared with the processor?s program counter register, as defined in the tdr . the pbr is accessible in supervisor mode as debug control register $8 using the wdebug instruction and through the bdm port using the rdmreg and wdmreg commands. the pbmr is accessible in supervisor mode as debug control register $9 using the wdebug instruction and through the bdm port using the wdmreg command. tm [2:0] the transfer modifier field is compared with the transfer modifier signals of the processor?s local bus. the signals provide supplemental information for each transfer type. the encoding for normal processor transfers (tt = 0) is: 000 = explicit cache line push 001 = user data access 010 = user code access 011 = reserved 100 = reserved 101 = supervisor data access 110 = supervisor code access 111 = reserved the encoding for emulator mode transfers (tt = 10) is: 0xx = reserved 100 = reserved 101 = emulator mode data access 110 = emulator mode code access 111 = reserved the encoding for acknowledge/cpu space transfers (tt = 11) is: 000 = cpu space access 001 = interrupt acknowledge level 1 010 = interrupt acknowledge level 2 011 = interrupt acknowledge level 3 100 = interrupt acknowledge level 4 101 = interrupt acknowledge level 5 110 = interrupt acknowledge level 6 111 = interrupt acknowledge level 7 these bits also define the tm encoding for bdm memory commands (for backward compatibility). table 19-25 address attribute trigger bit descriptions bit name description 19-32 mcf5249um motorola real-time debug support address[31:0]?pc breakpoint address this field contains the 32-bit address to be compared with the pc as a breakpoint trigger. mask[31:0]?pc breakpoint mask this field contains the 32-bit mask for the pc breakpoint trigger. a zero in a bit position causes the corresponding bit in the pbr to be compared to the appropriate bit of the pc. a one causes that bit to be ignored. 19.4.2.4 data breakpoint registers (dbr, dbmr) the data breakpoint registers (dbr and dbmr) define a specific data pattern that can be used as part of the trigger into debug mode.the dbr value is masked by the dbmr value, allowing only those bits in dbr that have a corresponding zero in dbmr to be compared with the data value from the processor?s local bus, as defined in the tdr . the dbr is accessible in supervisor mode as debug control register $e using the wdebug instruction and through the bdm port using the rdmreg and wdmreg commands. the dbmr is accessible in supervisor mode as debug control register $f using the wdebug instruction and through the bdm port using the wdmreg command. the dbr is overwritten by the bdm hardware when accessing memory as described in section 19.4.1.2 debug module hardware. table 19-26 program counter breakpoint register (pbr) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field address[31:0] reset---------------- r/w write only bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field address[31:0] reset---------------- r/w write only table 19-27 program counter breakpoint mask register (pbmr) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field mask [31:0] reset---------------- r/w write only bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field mask [31:0] reset---------------- r/w write only addr real-time debug support motorola section 19 debug support 19-33 data[31:0]?data breakpoint value this field contains the 32-bit value to be compared with the data value from the processor?s local bus as a breakpoint trigger. mask[31:0]?data breakpoint mask this field contains the 32-bit mask for the data breakpoint trigger. a zero in a bit position causes the corresponding bit in the dbr to be compared to the appropriate bit of the internal data bus. a one causes that bit to be ignored the data breakpoint register supports both aligned and misaligned references. the relationship between the processor address, the access size, and the corresponding location within the 32-bit data bus is shown in table 19-30 . . table 19-28 data breakpoint register (dbr) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field address [31:0] reset---------------- r/w write only addr bits 1514131211109876543210 field address [31:0] reset---------------- r/w write only table 19-29 data breakpoint mask register (dbmr) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field mask [31:0] reset---------------- r/w write only bits 1514131211109876543210 field mask [31:0] reset---------------- r/w write only 19-34 mcf5249um motorola real-time debug support 19.4.2.5 trigger definition register (tdr) the tdr configures the operation of the hardware breakpoint logic within the debug module and controls the actions taken under the defined conditions. the breakpoint logic may be configured as a one- or two-level trigger, where bits [31:16] of the tdr define the 2nd level trigger and bits [15:0] define the first level trigger. the tdr is accessible in supervisor mode as debug control register $7 using the wdebug instruction and through the bdm port using the wdmreg command. table 19-30 access and operand data location address[1:0] access size operand location 00 byte data[31:24] 01 byte data[23:16] 10 byte data[15:8] 11 byte data[7:0] 0x word data[31:16] 1x word data[15:0] xx long data[31:0] real-time debug support motorola section 19 debug support 19-35 table 19-31 trigger definition register (tdr) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field trc trc edlw edwl edwu edll edlm edum eduu di eai ear eal epc pci reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r/w write only bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field lxt ebl edlw edwl edwu edll edlm edum eduu di eai ear eal epc pci reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r/w write only table 19-32 trigger definition bit descriptions bit name description trc the trigger response control determines how the processor is to respond to a completed trigger condition. the trigger response is always displayed on the ddata pins. 00 = display on ddata only 01 = processor halt 10 = debug interrupt 11 = reserved tdr[15] 0 = level-2 trigger = pc_condition & address_range & data_condition 1 = level-2 trigger = pc_condition | (address_range & data_condition) tdr[14] 0 = level-1 trigger = pc_condition & address_range & data_condition 1 = level-1 trigger = pc_condition | (address_range & data_condition) ebl if set, the enable breakpoint level bit serves as the global enable for the breakpoint trigger. if cleared, all breakpoints are disabled. edlw if set, the enable data breakpoint for the data longword bit enables the data breakpoint based on the entire processor?s local data bus. the assertion of any of the ed bits enables the data breakpoint. if all bits are cleared, the data breakpoint is disabled. edwl if set, the enable data breakpoint for the lower data word bit enables the data breakpoint based on the low-order word of the processor?s local data bus. edwu if set, the enable data breakpoint for the upper data word bit enables the data breakpoint trigger based on the high-order word of the processor?s local data bus. edll if set, the enable data breakpoint for the lower data byte bit enables the data breakpoint trigger based on the low-order byte of the low-order word of the processor?s local data bus. edlm if set, the enable data breakpoint for the lower lower middle data byte bit enables the data breakpoint trigger based on the high-order byte of the low-order word of the processor?s local data bus. edum if set, the enable data breakpoint for the upper middle data byte bit enables the data breakpoint trigger on the low-order byte of the high-order word of the processor?s local data bus. eduu if set, the enable data breakpoint for the upper upper data byte bit enables the data breakpoint trigger on the high-order byte of the high-order word of the processor?s local data bus. di the data breakpoint invert bit provides a mechanism to invert the logical sense of all the data breakpoint comparators. this can develop a trigger based on the occurrence of a data value not equal to the one programmed into the dbr. 19-36 mcf5249um motorola real-time debug support 19.4.2.6 configuration/status register (csr) the csr defines the debug configuration for the processor and memory subsystem. in addition to defining the microprocessor configuration, this register also contains status information from the breakpoint logic. the csr is cleared during system reset. the csr can be read and written by the external development system and written by the supervisor programming model. the csr is accessible in supervisor mode as debug control register $0 using the wdebug instruction and through the bdm port using the rdmreg and wdmreg commands. eai if set, the enable address breakpoint inverted bit enables the address breakpoint based outside the range defined by ablr and abhr. the assertion of any of the ea bits enables the address breakpoint. if all three bits are cleared, this breakpoint is disabled. ear if set, the enable address breakpoint range bit enables the address breakpoint based on the inclusive range defined by ablr and abhr. eal if set, the enable address breakpoint low bit enables the address breakpoint based on the address contained in the ablr. epc if set, the enable pc breakpoint bit enables the pc breakpoint. pci if set, the pc breakpoint invert bit allows execution outside a given region as defined by pbr and pbmr to enable a trigger. if cleared, the pc breakpoint is defined within the region defined by pbr and pbmr. table 19-32 trigger definition bit descriptions bit name description real-time debug support motorola section 19 debug support 19-37 table 19-33 configuration/status register (csr) bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field status fof trg halt bkpt hrl - bkd pcd ipw reset 0 0 0 0 0 0 0 0 0 r/w read only r r r r read only - - r/w r/w addr bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 field map trc emu ddc uhe btb - npl ipi ssm - reset 0 0 0 0 0 0 0 0 0 0 0 0 - r/w r/w r/w r/w r/w r/w r/w r r/w r/ w r/w addr note: the csr is a write only register from the pr ogramming model. it can be read from and written to through the bdm port. table 19-34 configuration/status bit descriptions bit name description status[31:28] the breakpoint status 4-bit field provides read-only status information concerning the hardware breakpoints. this field is defined as follows: 000x = no breakpoints enabled 001x = waiting for level 1 breakpoint 010x = level 1 breakpoint triggered 101x = waiting for level 2 breakpoint 110x = level 2 breakpoint triggered the breakpoint status is also output on the ddata port when it is not busy displaying other processor data. a write to the tdr resets this field. fof[27] if the read-only fault-on-fault status bit is set, a catastrophic halt has occurred and forced entry into bdm. this bit is cleared on a read from the csr. trg[26] if the read-only hardware breakpoint trigger status bit is set, a hardware breakpoint has halted the processor core and forced entry into bdm. this bit is cleared by reading csr. halt[25] if the read-only processor halt status bit is set, the processor has executed the halt instruction and forced entry into bdm. this bit is cleared by reading the csr. bkpt [24] if the read-only breakpoint assert status bit is set, the bkpt signal was asserted, forcing the processor into bdm. this bit is cleared on a read from the csr. hrl[23:20] this hardware revision level indicates the level of functionality implemented in the debug module. this information could be used by an emulator to identify the level of functionality supported. a zero value would indicate the initial debug functionality. for example, a value of 1 would represent revision a while a value of 0 would represent the earlier release of revision a. 19-38 mcf5249um motorola real-time debug support bkd[18] the disable the normal bkpt input signal functionality bit is used to disable the normal bkpt input signal functionality, and allow the assertion of this pin to generate a debug interrupt. if set, the assertion of the bkpt pin is treated as an edge-sensitive event. specifically, a high-to-low edge on the bkpt pin generates a signal to the processor indicating a debug interrupt. the processor makes this interrupt request pending until the next sample point occurs. at that time, the debug interrupt exception is initiated. in the coldfire architecture, the interrupt sample point occurs once per instruction. there is no support for any type of ?nesting? of debug interrupts. pcd[17] if set, the pstclk disable bit disables the generation of the pstclk output signal, and forces this signal to remain quiescent. ipw[16] if set, the inhibit processor writes to debug registers bit inhibits any processor-initiated writes to the debug module?s programming model registers. this bit can only be modified by commands from the external development system. map[15] if set, the force processor references in emulator mode bit forces the processor to map all references while in emulator mode to a special address space, tt = $2, tm = $5 or $6. if cleared, all emulator-mode references are mapped into supervisor code and data spaces. trc[14] if set, the force emulation mode on trace exception bit forces the processor to enter emulator mode when a trace exception occurs. emu[13] if set, the force emulation mode bit forces the processor to begin execution in emulator mode. refer to section 19.4.1.1 emulator mode. ddc[12:11] the 2-bit debug data control field provides configuration control for capturing operand data for display on the ddata port. the encoding is: 00 = no operand data is displayed 01 = capture all m-bus write data 10 = capture all m-bus read data 11 = capture all m-bus read and write data in all cases, the ddata port displays the number of bytes defined by the operand reference size. for example, byte displays 8 bits, word displays 16 bits, and long displays 32 bits (one nibble at a time across multiple clock cycles.) refer to section 19.2.1.7 begin data transfer (pst = $8?$b). uhe[10] the user halt enable bit selects the cpu privilege level required to execute the halt instruction. 0 = halt is a privileged, supervisor-only instruction 1 = halt is a non-privileged, supervisor/user instruction btb[9:8] the 2-bit branch target bytes field defines the number of bytes of branch target address to be displayed on the ddata outputs. the encoding is: 00 = 0 bytes 01 = lower two bytes of the target address 10 = lower three bytes of the target address 11 = entire four-byte target address refer to section 19.2.1.5 begin execution of taken branch (pst = $5). table 19-34 configuration/status bit descriptions bit name description real-time debug support motorola section 19 debug support 19-39 19.4.2.7 bdm address attribute (baar) the baar register defines the address space for memory-referencing bdm commands. bits [7:5] are loaded directly from the bdm command, while the low-order 5 bits can be programmed from the external development system. to maintain compatibility with the rev. a implementation, this register is loaded any time the aatr is written. the bar is initialized to a value of $5, setting ?supervisor data? as the default address space. npl[6] if set, the non-pipelined mode bit forces the processor core to operate in a nonpipeline mode of operation. in this mode, the processor effectively executes a single instruction at a time with no overlap. when operating in non-pipelined mode, performance is severely degraded. for the v3 design, operation in this mode essentially adds 6 cycles to the execution time of each instruction. given that the measured effective cycles per instruction for v3 is ~2 cycles/instruction, meaning performance in non-pipeline mode would be ~8 cycles/instruction, or approximately 25% compared to the pipelined performance. regardless of the state of csr[6], if a pc breakpoint is triggered, it is always reported before the instruction with the breakpoint is executed. the occurrence of an address and/or data breakpoint trigger is imprecise in normal pipeline operation. when operating in non-pipeline mode, these triggers are always reported before the next instruction begins execution. in this mode, the trigger reporting can be considered to be precise. as previously detailed, the occurrence of an address and/or data breakpoint should always happen before the next instruction begins execution. therefore the occurrence of the address/data breakpoints should be guaranteed. ipi[5] if set, the ignore pending interrupts bit forces the processor core to ignore any pending interrupt requests signalled while executing in single-instruction-step mode. ssm[4] if set, the single-step mode bit forces the processor core to operate in a single-instruction-step mode. while in this mode, the processor executes a single instruction and then halts. while halted, any of the bdm commands may be executed. on receipt of the go command, the processor executes the next instruction and then halts again. this process continues until the single-instruction-step mode is disabled. table 19-35 bdm address attribute register (baar) bits 7 6 5 4 3 2 1 0 field r sz tt tm reset 00000101 r/w write only table 19-34 configuration/status bit descriptions bit name description 19-40 mcf5249um motorola real-time debug support 19.4.3 concurrent bdm and processor operation the debug module supports concurrent operation of both the processor and most bdm commands. bdm commands may be executed while the processor is running, except for the operations that access processor/memory registers: read/write address and data registers read/write control registers for bdm commands that access memory, the debug module requests the processor?s local bus. the processor responds by stalling the instruction fetch pipeline and then waiting until all current bus activity is complete. at that time, the processor relinquishes the local bus to allow the debug module to perform the required operation. after the conclusion of the debug module bus cycle, the processor reclaims ownership of the bus. the development system must use caution in configuring the breakpoint registers if the processor is executing. the debug module does not contain any hardware interlocks, so motorola recommends that the tdr be disabled while the breakpoint registers are being loaded. at the conclusion of this process, the tdr can be written to define the exact trigger. this approach guarantees that no spurious breakpoint triggers occur. because there are no hardware interlocks in the debug unit, no bdm operations are allowed while the cpu is writing the debug?s registers (bkpt and dsclk must be inactive). table 19-36 bdm address attr ibute (baar) bit descriptions bit name description r[7] 0 = write 1 = read sz[6:5] size 00 = longword 01 = byte 10 = word 11 = reserved tt[4:3] transfer type see the tt definition in the aatr description, section 19.4.2.2 address attribute trigger register. tm[2:0] transfer modifier see the tm definition in the aatr description, section 19.4.2.2 address attribute trigger register. real-time debug support motorola section 19 debug support 19-41 19.4.4 motorola-recommended bdm pinout the coldfire bdm connector is a 26-pin berg connector arranged 2x13, shown in figure 19-26 . figure 19-26 recommended bdm connector 1 3 5 7 9 11 13 15 17 19 21 23 25 2 4 6 8 10 12 14 16 18 20 22 24 26 developer reserved gnd gnd reset +3.3v1 gnd pst2 pst0 ddata2 ddata0 motorola reserved gnd vdd_cpu1 bkpt dsclk developer reserved dsi dso pst3 pst1 ddata3 ddata1 gnd motorola reserved pstclk ta notes: 1. supplied by target 2. pins reserved for bdm developer use. contact developer. 19-42 mcf5249um motorola notes motorola section 20 ieee 1149.1 test access port (jtag) 20-1 section 20 ieee 1149.1 test ac cess port (jtag) the mcf5249 jtag test architecture implementation currently supports circuit board test strategies that are based on the ieee standard. this architecture provides access to all of the data and chip control pins from the board edge connector through the standard four-pin test access port (tap) and the active-low jtag reset pin, trst . the test logic uses static design and is wholly independent of the system logic, except where the jtag is subordinate to other complimentary test modes (see the debug section, for more information). when in subordinate mode, the jtag test logic is placed in reset and the tap pins can be used for other purposes in accordance with the rules and restrictions set forth using a jtag compliance-enable pin. the mcf5249 jtag implementation can do the following: perform boundary-scan operations to test circuit board electrical continuity bypass the mcf5249 by reducing the shift register path to a single cell sample the mcf5249 system pins during operation and transparently shift out the result set the mcf5249 output drive pins to fixed logic values while reducing the shift register path to a single cell protect the mcf5249 system output and input pins from backdriving and random toggling (such as during in-circuit testing) by placing all system signal pins to high- impedance state note: the ieee standard 1149.1 test logic cannot be considered completely benign to those planning not to use jtag capability. users must observe certain precautions to ensure that this logic does not interfere with system or debug operation. refer to section 20.6 disabling ieee 1149.1a standard operation . 20.1 jtag overview figure 20-1 is a block diagram of the mcf5249 implementation of the 1149.1 ieee standard. the test logic includes several test data registers, an instruction register, instruction register control decode, and a 16-state dedicated tap controller. 20-2 mcf5249um motorola jtag signal descriptions figure 20-1 jtag test logic block diagram 20.2 jtag signal descriptions the jtag operation on the mcf5249 is enabled when test[3:0]= 0000, in which case the external pin descriptions in table 20-1 apply.otherwise, the jtag test access port signals (tck/tms/tdi/tdo/trst) are interpreted as the debug port pins. bypass 4-bit instruction decode 4-bit instruction register mux tap controller test data registers tdi tms tck trst tdo v + boundary scan register idcode register m u x v + v + jtag signal descriptions motorola section 20 ieee 1149.1 test access port (jtag) 20-3 20.2.1 test clock - (tck) tck is the dedicated jtag test logic clock that is independent of the mcf5249 processor clock. various jtag operations occur on the rising or falling edge of tck. the internal jtag controller logic is designed such that holding tck high or low for an indefinite period of time will not cause the jtag test logic to lose state information. if tck is not used, it should be tied to vdd. there is an internal pullup connected to this pin. 20.2.2 test reset/development serial clock - (trst /dsclk) the test[3:0] signals determine the function of this dual-purpose pin. if test[3:0]=0001, the dsclk function is selected. if test[3:0]= 0000, the trst function is selected, the pin got an internal pullup and the jtag reset is executed. for all other modes the signal is forced internally to its active value. test[3:0] should not be changed while rsti is asserted. when used as trst , this pin asynchronously resets the internal jtag controller to the test logic reset state, causing the jtag instruction register to choose the ?idcode? command. when this occurs, all the jtag logic is benign and will not interfere with the normal functionality of the mcf5249 processor. although this signal is asynchronous, motorola recommends that trst make only a 0 to 1 (asserted to negated) transition while tms is held at a logic 1 value. trst has an internal pullup so that if it is not driven low its value will default to a logic level of 1. however, if trst will not be used, it can either be tied to ground or, if tck is clocked, it can be tied to vdd. the former connection will place the jtag controller in the test logic reset state immediately, while the later connection will cause the jtag controller (if tms is a logic 1) to eventually end up in the test logic reset state after 5 clocks of tck. this pin is also used as the development serial clock (dsclk) for the serial interface to the debug module.the maximum frequency for the dsclk signal is 1/2 the bclko frequency. 20.2.3 test mode select/ breakpoint (tms/bkpt ) the test[3:0] signals determine this pin?s dual function. if test[3:0] =0001, the bkpt function is selected. if test[3:0] = 0000, then the tms function is selected. test[3:0] should not change while rsti is asserted. when used as tms, this input signal provides the jtag controller with information to determine which test operation mode should be performed. the value of tms and current state of the internal 16-state jtag controller state machine at the rising edge of tck determine whether the jtag controller holds its current state or advances to the next state. this directly controls whether jtag data or instruction table 20-1 jtag pin descriptions pin description tck a test clock input that synchronizes test logic operations tms a test mode select input with a default internal pullup resistor that is sampled on the rising edge of tck to sequence the tap controller tdi a serial test data input with a default internal pullup resistor that is sampled on the rising edge of tck tdo a three-state test data output that is actively driven only in the shift-ir and shift-dr controller states and only updates on the falling edge of tck trst an active-low asynchronous reset with a default internal pullup resistor that forces the tap controller into the test-logic-reset state. 20-4 mcf5249um motorola tap controller operations occur. tms has an internal pullup so that if it is not driven low, its value will default to a logic level of 1. however, if tms will not be used, it should be tied to vdd. this pin also signals a hardware breakpoint to the processor when in the debug mode. 20.2.4 test data input/developm ent serial input - (tdi/dsi) this is a dual-function pin. if test[3:0] = 0001, then dsi is selected. if test[3:0] = 0000, then tdi is selected. when used as tdi, this input signal provides the serial data port for loading the various jtag shift registers composed of the boundary scan register, the bypass register, and the instruction register. shifting in of data depends on the state of the jtag controller state machine and the instruction currently in the instruction register. this data shift occurs on the rising edge of tck. tdi also has an internal pullup so that if it is not driven low its value will default to a logic level of 1. however, if tdi will not be used, it should be tied to vdd. this pin also provides the single-bit communication for the debug module commands. 20.2.5 test data output/developmen t serial output - (tdo/dso) this is a dual-function pin. when test[3:0] = 0001, then dso is selected. when test[3:0] = 0000, tdo is selected. when used as tdo, this output signal provides the serial data port for outputting data from the jtag logic. shifting out of data depends on the state of the jtag controller state machine and the instruction currently in the instruction register. this data shift occurs on the falling edge of tck. when tdo is not outputting test data, it is three-stated. tdo can also be placed in three-state mode to allow bussed or parallel connections to other devices having jtag. 20.3 tap controller the state of tms at the rising edge of tck determines the current state of the tap controller. there are basically two paths that the tap controller can follow: the first, for executing jtag instructions; the second, for manipulating jtag data based on the jtag instructions. the various states of the tap controller are shown in figure 20-2 . for more detail on each state, refer to the ieee 1149.1a standard jtag document. note: from any state that the tap controller is in, test-logic-reset can be entered if tms is held high for at least five rising edges of tck. tap controller motorola section 20 ieee 1149.1 test access port (jtag) 20-5 figure 20-2 jtag tap controller state machine test - logic - reset tlr run - test - idle rti select - dr - scan sedr capture - ir update - ir exit2 - ir pause - ir exit1 - ir shift - ir capture - dr update - dr exit2 - dr pause - dr exit1 - dr shift - dr 0 0 0 1 0 1 1 0 0 0 1 1 0 1 1 1 11 0 11 11 00 0 1 cadr shdr e1dr padr e2dr updr cair shir e1ir pair e2ir upir <-- value of tms at rising edge of tck select - ir - scan seir 1 0 0 0 1 0 20-6 mcf5249um motorola jtag registers 20.4 jtag registers 20.4.1 jtag instruction shift register the mcf5249 ieee 1149.1a standard implementation uses a 4-bit instruction-shift register without parity. this register transfers its value to a parallel hold register and applies one of eight possible instructions on the falling edge of tck when the tap state machine is in the update-ir state. to load the instructions into the shift portion of the register, place the serial data on the tdi pin prior to each rising edge of tck. the msb of the instruction shift register is the bit closest to the tdi pin and the lsb is the bit closest to the tdo pin. table 20-2 lists the public, usable instructions that are supported along with their encoding. the ieee 1149.1a standard requires the extest, sample/preload, and bypass instructions. idcode, clamp, highz are optional standard instructions that the mcf5249 implementation supports and are described in the ieee standard 1149.1. the ringosc and orgate are user defined instructions only used for device test during manufacturing. 20.4.1.1 extest instruction the external test instruction (extest) selects the boundary-scan register. the extest instruction forces all output pins and bidirectional pins configured as outputs to the preloaded fixed values (with the sample/preload instruction) and held in the boundary-scan update registers. the extest instruction can also configure the direction of bidirectional pins and establish high-impedance states on some pins. the extest instruction becomes active on the falling edge of tck in the update-ir state when the data held in the instruction-shift register is equivalent to hex 0. 20.4.1.2 idcode the idcode instruction selects the 32-bit idcode register for connection as a shift path between the tdi pin and the tdo pin. this instruction lets users interrogate the mcf5249 to determine its version number table 20-2 jtag instructions instruction abbr class ir[ 3:0] instruction summary extest ext required 0000 select bs register while applying fixed values to output pins and asserting functional reset idcode idc optional 0001 selects idcode register for shift sample/ preload smp required 0010 selects bs register for shift, sample, and preload without disturbing functional operation clamp cmp optional 0011 selects bypass while applying fixed values to output pins and asserting functional reset highz hiz optional 0100 selects the bypass register while three-stating all output pins and asserting functional reset ringosc ring optional 0111 user defined function for device test orgate or optional 1000 user defined function for device test bypass byp required 1111 selects the bypass register for data operations jtag registers motorola section 20 ieee 1149.1 test access port (jtag) 20-7 and other part identification data. the idcode register has been implemented in accordance with ieee 1149.1a so that the least significant bit of the shift register stage is set to logic 1 on the rising edge of tck following entry into the capture-dr state. therefore, the first bit to be shifted out after selecting the idcode register is always a logic 1. the remaining 31-bits are also set to fixed values (see section 20.4.2 idcode register ) on the rising edge of tck following entry into the capture-dr state. the idcode instruction is the default value placed in the instruction register when a jtag reset is accomplished by either asserting trst or holding tms high while clocking tck through at least five rising edges and the falling edge after the fifth rising edge. a jtag reset will cause the tap state machine to enter the test-logic-reset state (normal operation of the tap state machine into the test-logic-reset state will also result in placing the default value of octal 1 into the instruction register). the shift register portion of the instruction register is loaded with the default value of hex 1 when in the capture-ir state and a rising edge of tck occurs. 20.4.1.3 sample/preload instruction the sample/preload instruction provides two separate functions. first, it obtains a sample of the system data and control signals present at the mcf5249 input pins and just prior to the boundary scan cell at the output pins. this sampling occurs on the rising edge of tck in the capture-dr state when an instruction encoding of hex 2 is resident in the instruction register. users can observe this sampled data by shifting it through the boundary-scan register to the output tdo by using the shift-dr state. both the data capture and the shift operation are transparent to system operation. users are responsible for providing some form of external synchronization to achieve meaningful results because there is no internal synchronization between tck and the system clock, clk. the second function of the sample/preload instruction is to initialize the boundary scan register update cells before selecting extest or clamp. this is achieved by ignoring the data being shifted out of the tdo pin while shifting in initialization data. the update-dr state in conjunction with the falling edge of tck can then transfer this data to the update cells. this data will be applied to the external output pins when one of the instructions listed above is applied. 20.4.1.4 clamp instruction the clamp instruction selects the bypass register and asserts functional reset while simultaneously forcing all output pins and bidirectional pins configured as outputs to the fixed values that are preloaded and held in the boundary-scan update registers. this instruction enhances test efficiency by reducing the overall shift path to a single bit (the bypass register) while conducting an extest type of instruction through the boundary-scan register. the clamp instruction becomes active on the falling edge of tck in the update-ir state when the data held in the instruction-shift register is equivalent to hex 3. 20.4.1.5 highz instruction the highz instruction anticipates the need to backdrive the output pins and protect the input pins from random toggling during circuit board testing. the highz instruction selects the bypass register, forcing all output and bidirectional pins to the high-impedance state. the highz instruction goes active on the falling edge of tck in the update-ir state when the data held in the instruction shift register is equivalent to hex 4. 20.4.1.6 bypass instruction the bypass instruction selects the single-bit bypass register, creating a single-bit shift register path from the tdi pin to the bypass register to the tdo pin. this instruction enhances test efficiency by reducing the overall shift path when a device other than the mcf5249 processor becomes the device under test on a board design with multiple chips on the overall 1149.1 defined boundary-scan chain. the bypass register 20-8 mcf5249um motorola jtag registers has been implemented in accordance with 1149.1 so that the shift register stage is set to logic zero on the rising edge of tck following entry into the capture-dr state. therefore, the first bit to be shifted out after selecting the bypass register is always a logic zero (to differentiate a part that supports an idcode register from a part that supports only the bypass register). the bypass instruction goes active on the falling edge of tck in the update-ir state when the data held in the instruction shift register is equivalent to hex f. 20.4.2 idcode register an ieee 1149.1a compliant jtag identification register has been included on the mcf5249. the mcf5249 jtag instruction encoded as hex 1 provides for reading the jtag idcode register. 20.4.3 jtag boundary scan register the mcf5249 model includes an ieee 1149.1a-compliant boundary-scan register. the boundary-scan register is connected between tdi and tdo when the extest or sample/preload instructions are selected. this register captures signal pin data on the input pins, forces fixed values on the output signal pins, and selects the direction and drive characteristics (a logic value or high impedance) of the bidirectional and three-state signal pins. a detailed description of the boundary scan register bits for the mcf5249 is part of the bsdl file listed in 20.7 mcf5249 bsdl file on page 10 . table 20-3 id code register command bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 field version number design center device number reset 001001010100000 0 r/w addr bits151413121110987654321 0 field device number jedecid jtagid reset 011000000001110 1 r/w addr table 20-4 id code bit descriptions bit name description bits 31-28 the version number bits indicate the revision number of the mcf5249. bits 27-22 the design center bits indicate the munich design center. bits 21-12 the device number bits indicate an mcf5249. bits 11-1 the jedec id bits indicate the reduced jedec id for motorola (jedec refers to the joint electron device engineering council. refer to jedec publication 106-a and section 11 of the ieee 1149.1a standard for further information on this field). bit 0 differentiates this register as the jtag id code register (as opposed to the bypass register) according to the ieee 1149.1a standard. restrictions motorola section 20 ieee 1149.1 test access port (jtag) 20-9 20.4.4 jtag bypass register the mcf5249 includes an ieee 1149.1a-compliant bypass register, which creates a single bit shift register path from tdi to the bypass register to tdo when the bypass instruction is selected. 20.5 restrictions the test logic is implemented using static logic design, and tck can be stopped in either a high or low state without loss of data. the system logic, however, operates on a different system clock which is not synchronized to tck internally. any mixed operation requiring the use of 1149.1 test logic in conjunction with system functional logic that uses both clocks, must have coordination and synchronization of these clocks done externally to the mcf5249. 20.6 disabling ieee 1149.1a standard operation there are two ways to use the mcf5249 without the ieee 1149.1a test logic being active: 1. nonuse of the jtag test logic by either nontermination (disconnection) or intentional fixing of tap logic values. 2. intentional disabling of the jtag test logic by setting test[3:0]= 0001 (entering debug mode) there are several considerations that must be addressed if the ieee 1149.1a logic is not going to be used once the mcf5249 is assembled onto a board. the prime consideration is to ensure that the ieee 1149.1a test logic remains transparent and benign to the system logic during functional operation. this requires the minimum of either connecting the trst pin to logic 0, or connecting the tck clock pin to a clock source that will supply five rising edges and the falling edge after the fifth rising edge, to ensure that the part enters the test-logic-reset state. the recommended solution is to connect trst to logic 0. another consideration is that the tck pin does not have an internal pullup as is required on the tms, tdi, and trst pins; therefore, it should not be left unterminated to preclude mid-level input values. figure 20-3 shows pin values recommended for disabling jtag with the mcf5249 in jtag mode. . figure 20-3 disabling jtag in jtag mode a second method of using the mcf5249 without the ieee 1149.1a logic being active is to select debug mode by setting test[3:0]= 0001. the ieee 1149.1a test controller is now placed in the test-logic-reset tdi/dsi tck v dd trst /dsclk tms/bkpt ? ? ? note: test[3:0] set to ? 0001? allows jtag mode. 20-10 mcf5249um motorola mcf5249 bsdl file state by the internal assertion of the trst signal to the controller and the tap pins function as debug mode pins. while in jtag mode, input pins tdi/dsi, tms/bkpt , and trst /dsclk have internal pullups enabled. figure 20-4 shows pin values recommended for disabling jtag with the mcf5249 in debug mode. figure 20-4 disabling jtag in debug mode 20.7 mcf5249 bsdl file -- ------------------------------------------------------------------------- -- -- bsdl file for design xcf5249 -- -- ------------------------------------------------------------------------- -- -- creation date mon oct 1 10:27:32 2001 -- ------------------------------------------------------------------------- -- -- -- -- this information is provided on an as is basis and without warranty. -- -- in no event shall motorola be liable for incidental or consequential -- -- damages arising from use of this information. this disclaimer of -- -- warranty extends to the user of the information, and to their customers -- -- or users of products and is in lieu of all warranties whether express, -- -- implied, or statutory, including implied warranties of merchantability -- -- or fitness for particular purpose. -- -- -- -- motorola does not represent or warrant that the information furnished -- -- hereunder is free of infringement of any third party patents, -- -- copyrights, trade secrets, or other intellectual property rights. -- -- motorola does not represent or warrant that the information is free of -- -- defect, or that it meets any particular standard, requirements or need -- -- of the user of the information or their customers. -- -- -- -- motorola reserves the right to change the information in this file -- -- without notice. -- -- -- -- ------------------------------------------------------------------------- -- -- -- -- technical note -- -- -- -- ------------------------------------------------------------------------- -- tdi /dsi tck debug interface trst /dsclk tms/bkpt note: test[3:0] not set to? 0001? prohibits jtag. mcf5249 bsdl file motorola section 20 ieee 1149.1 test access port (jtag) 20-11 entity xcf5249 is generic (physical_pin_map: string:= ?bga160?); port ( scl_qspiclk_pin : inout bit ; cs0_pin : out bit ; a21_pin : out bit ; a11_pin : out bit ; a10_pin : out bit ; a9_pin : out bit ; cmdsdio2_gp34_pin : inout bit ; a18_pin : out bit ; a17_pin : out bit ; bclk_gp10_pin : inout bit ; sclkout_gp15_pin : inout bit ; bclke_pin : out bit ; sda_qspidin_pin : inout bit ; data24_pin : inout bit ; a22_pin : out bit ; sdudqm_pin : out bit ; ef_gp19_pin : inout bit ; sdata0sdio1_gp54_pin : inout bit ; data25_pin : inout bit ; data26_pin : inout bit ; sdata2bs2_rsto_pin : inout bit ; data27_pin : inout bit ; data28_pin : inout bit ; data29_pin : inout bit ; sdata3_gp56_pin : inout bit ; data30_pin : inout bit ; bufenb1_gp57_pin : inout bit ; data31_pin : inout bit ; a13_pin : out bit ; a25_gpo8_pin : out bit ; a23_pin : out bit ; a14_pin : out bit ; a15_pin : out bit ; a16_pin : out bit ; a19_pin : out bit ; a20_pin : out bit ; qspics1_gp24_pin : inout bit ; test2_pin : in bit ; sdramcs1_pin : out bit ; sdata1bs1_gp9_pin : inout bit ; sdras_pin : out bit ; sdcas_pin : out bit ; sdwe_pin : out bit ; sdldqm_pin : out bit ; gp5_pin : inout bit ; qspics0_gp29_pin : inout bit ; qspidout_gp26_pin : inout bit ; gp6_pin : inout bit ; data21_pin : inout bit ; 20-12 mcf5249um motorola mcf5249 bsdl file data19_pin : inout bit ; qspics2_gp21_pin : inout bit ; data20_pin : inout bit ; data22_pin : inout bit ; data18_pin : inout bit ; data23_pin : inout bit ; data17_pin : inout bit ; qspics3_gp22_pin : inout bit ; data16_pin : inout bit ; sdramcs2_gp7_pin : inout bit ; ebuout2_gpo37_pin : out bit ; cflg_gp18_pin : inout bit ; ebuout1_gpo36_pin : out bit ; ebuin3_adin0_gpi38_pin : in bit ; ebuin2_gpi37_pin : in bit ; scl2_gp3_pin : inout bit ; rsti_pin : in bit ; tout1_gpo35_pin : out bit ; lrck2_gp44_pin : inout bit ; oe_pin : out bit ; sda2_gp55_pin : inout bit ; sdatao2_gpo41_pin : out bit ; sclk2_gp48_pin : inout bit ; bufenb2_gp17_pin : inout bit ; test3_pin : in bit ; sdatao1_gp25_pin : inout bit ; lrck1_pin : inout bit ; lrck4_gp46_pin : inout bit ; sdatai4_gpi42_pin : in bit ; sclk1_pin : inout bit ; sclk4_gp50_pin : inout bit ; ta_gp20_pin : inout bit ; sdatai1_pin : in bit ; ebuin1_gpi36_pin : in bit ; pllgvdd : linkage bit ; pllggnd : linkage bit ; pll1gnd : linkage bit ; pll1vdd : linkage bit ; pllcgnd : linkage bit ; pllcvdd : linkage bit ; idediow_gp14_pin : inout bit ; crin_pin : in bit ; idedior_gp13_pin : inout bit ; iordy_gp16_pin : inout bit ; cl11_gpo39_pin : out bit ; subr_gp53_pin : inout bit ; cl16_gpo42_pin : out bit ; xtrim_gpo38_pin : out bit ; trst_dsclk_pin : in bit ; sfsy_gp52_pin : inout bit ; rw_b_pin : out bit ; rck_gp51_pin : inout bit ; tms_bkpt_pin : in bit ; tck_pin : in bit ; mcf5249 bsdl file motorola section 20 ieee 1149.1 test access port (jtag) 20-13 dbdcpst3_gp62_pin : inout bit ; cnpstclk_gp63_pin : out bit ; dbdcpst1_gp60_pin : inout bit ; dbdcpst2_gp61_pin : inout bit ; dbdcpst0_gp59_pin : inout bit ; tdi_dsi_pin : in bit ; test0_pin : in bit ; tin0_gpi33_pin : in bit ; hiz_b_pin : in bit ; dbdcddata3_gp4_pin : inout bit ; tout0_gpo33_pin : out bit ; dbdcddata1_gp1_pin : inout bit ; dbdcddata2_gp2_pin : inout bit ; cts2_adin3_gpi31_pin : in bit ; dbdcddata0_gp0_pin : inout bit ; rxd2_adin2_gpi28_pin : in bit ; tdo_dso_pin : out bit ; rts2_gpo31_pin : out bit ; sdatai3_gpi41_pin : in bit ; cts1_gpi30_pin : in bit ; txd2_gpo28_pin : out bit ; rts1_gpo30_pin : out bit ; ebuin4_adin1_gpi39_pin : in bit ; sre_gp11_pin : inout bit ; lrck3_gp45_pin : inout bit ; swe_gp12_pin : inout bit ; txd1_gpo27_pin : out bit ; sclk3_gp49_pin : inout bit ; rxd1_gpi27_pin : in bit ; cs1_gp58_pin : inout bit ; a1_pin : out bit ; tin1_gp23_pin : inout bit ; a2_pin : out bit ; a3_pin : out bit ; a4_pin : out bit ; a6_pin : out bit ; a5_pin : out bit ; a8_pin : out bit ; a7_pin : out bit ; a12_pin : out bit ; test1_pin : in bit ; gnd33 : linkage bit_vector (0 to 2) ; gnd18 : linkage bit_vector (0 to 3) ; vdd18 : linkage bit_vector (0 to 3) ; vdd33 : linkage bit_vector (0 to 4) ); use std_1149_1_1994.all; attribute component_conformance of xcf5249: entity is ?std_1149_1_1993?; attribute pin_map of xcf5249: entity is physical_pin_map; constant bga160: pin_map_string := 20-14 mcf5249um motorola mcf5249 bsdl file ?scl_qspiclk_pin : d04 , ? & ?cs0_pin : a01 , ? & ?a21_pin : d03 , ? & ?a11_pin : b01 , ? & ?a10_pin : c02 , ? & ?a9_pin : c01 , ? & ?cmdsdio2_gp34_pin : e03 , ? & ?a18_pin : d02 , ? & ?a17_pin : d01 , ? & ?bclk_gp10_pin : e02 , ? & ?sclkout_gp15_pin : f03 , ? & ?bclke_pin : e01 , ? & ?sda_qspidin_pin : e04 , ? & ?data24_pin : f02 , ? & ?a22_pin : g03 , ? & ?sdudqm_pin : f01 , ? & ?ef_gp19_pin : f04 , ? & ?sdata0sdio1_gp54_pin : g04 , ? & ?data25_pin : g01 , ? & ?data26_pin : g02 , ? & ?sdata2bs2_rsto_pin : h03 , ? & ?data27_pin : h01 , ? & ?data28_pin : h02 , ? & ?data29_pin : j01 , ? & ?sdata3_gp56_pin : j03 , ? & ?data30_pin : j02 , ? & ?bufenb1_gp57_pin : j04 , ? & ?data31_pin : k01 , ? & ?a13_pin : k02 , ? & ?a25_gpo8_pin : k03 , ? & ?a23_pin : k04 , ? & ?a14_pin : l01 , ? & ?a15_pin : l02 , ? & ?a16_pin : m01 , ? & ?a19_pin : m02 , ? & ?a20_pin : n01 , ? & ?qspics1_gp24_pin : l04 , ? & ?test2_pin : m03 , ? & ?sdramcs1_pin : n02 , ? & ?sdata1bs1_gp9_pin : m04 , ? & ?sdras_pin : p01 , ? & ?sdcas_pin : p02 , ? & ?sdwe_pin : n03 , ? & ?sdldqm_pin : p03 , ? & ?gp5_pin : n04 , ? & ?qspics0_gp29_pin : p04 , ? & ?qspidout_gp26_pin : n05 , ? & ?gp6_pin : l05 , ? & ?data21_pin : p05 , ? & ?data19_pin : n06 , ? & ?qspics2_gp21_pin : l06 , ? & ?data20_pin : p06 , ? & ?data22_pin : l07 , ? & ?data18_pin : p07 , ? & mcf5249 bsdl file motorola section 20 ieee 1149.1 test access port (jtag) 20-15 ?data23_pin : k07 , ? & ?data17_pin : n07 , ? & ?qspics3_gp22_pin : l08 , ? & ?data16_pin : p08 , ? & ?sdramcs2_gp7_pin : n08 , ? & ?ebuout2_gpo37_pin : p09 , ? & ?cflg_gp18_pin : l09 , ? & ?ebuout1_gpo36_pin : n09 , ? & ?ebuin3_adin0_gpi38_pin : p10 , ? & ?ebuin2_gpi37_pin : n10 , ? & ?scl2_gp3_pin : p11 , ? & ?rsti_pin : p12 , ? & ?tout1_gpo35_pin : n11 , ? & ?lrck2_gp44_pin : p13 , ? & ?oe_pin : n12 , ? & ?sda2_gp55_pin : m11 , ? & ?sdatao2_gpo41_pin : p14 , ? & ?sclk2_gp48_pin : n13 , ? & ?bufenb2_gp17_pin : k11 , ? & ?test3_pin : m12 , ? & ?sdatao1_gp25_pin : l12 , ? & ?lrck1_pin : n14 , ? & ?lrck4_gp46_pin : m13 , ? & ?sdatai4_gpi42_pin : m14 , ? & ?sclk1_pin : l13 , ? & ?sclk4_gp50_pin : l14 , ? & ?ta_gp20_pin : l11 , ? & ?sdatai1_pin : k13 , ? & ?ebuin1_gpi36_pin : k12 , ? & ?pllgvdd : k14 , ? & ?pllggnd : j11 , ? & ?pll1gnd : j13 , ? & ?pll1vdd : j12 , ? & ?pllcgnd : j14 , ? & ?pllcvdd : h11 , ? & ?idediow_gp14_pin : h12 , ? & ?crin_pin : h14 , ? & ?idedior_gp13_pin : h13 , ? & ?iordy_gp16_pin : g11 , ? & ?cl11_gpo39_pin : g14 , ? & ?subr_gp53_pin : g12 , ? & ?cl16_gpo42_pin : g13 , ? & ?xtrim_gpo38_pin : f14 , ? & ?trst_dsclk_pin : f11 , ? & ?sfsy_gp52_pin : f13 , ? & ?rw_b_pin : e14 , ? & ?rck_gp51_pin : f12 , ? & ?tms_bkpt_pin : e13 , ? & ?tck_pin : e12 , ? & ?dbdcpst3_gp62_pin : d14 , ? & ?cnpstclk_gp63_pin : d13 , ? & ?dbdcpst1_gp60_pin : c14 , ? & ?dbdcpst2_gp61_pin : c13 , ? & ?dbdcpst0_gp59_pin : b14 , ? & 20-16 mcf5249um motorola mcf5249 bsdl file ?tdi_dsi_pin : d11 , ? & ?test0_pin : c12 , ? & ?tin0_gpi33_pin : b13 , ? & ?hiz_b_pin : c11 , ? & ?dbdcddata3_gp4_pin : a14 , ? & ?tout0_gpo33_pin : a13 , ? & ?dbdcddata1_gp1_pin : b12 , ? & ?dbdcddata2_gp2_pin : a12 , ? & ?cts2_adin3_gpi31_pin : b11 , ? & ?dbdcddata0_gp0_pin : a11 , ? & ?rxd2_adin2_gpi28_pin : b10 , ? & ?tdo_dso_pin : d10 , ? & ?rts2_gpo31_pin : a10 , ? & ?sdatai3_gpi41_pin : b09 , ? & ?cts1_gpi30_pin : d09 , ? & ?txd2_gpo28_pin : a09 , ? & ?rts1_gpo30_pin : d08 , ? & ?ebuin4_adin1_gpi39_pin : a08 , ? & ?sre_gp11_pin : e08 , ? & ?lrck3_gp45_pin : b08 , ? & ?swe_gp12_pin : e07 , ? & ?txd1_gpo27_pin : d07 , ? & ?sclk3_gp49_pin : a07 , ? & ?rxd1_gpi27_pin : b07 , ? & ?cs1_gp58_pin : a06 , ? & ?a1_pin : b06 , ? & ?tin1_gp23_pin : d06 , ? & ?a2_pin : a05 , ? & ?a3_pin : b05 , ? & ?a4_pin : a04 , ? & ?a6_pin : a03 , ? & ?a5_pin : b04 , ? & ?a8_pin : a02 , ? & ?a7_pin : b03 , ? & ?a12_pin : b02 , ? & ?test1_pin : c03 , ? & ?gnd33 : (h04,e11,d05) , ? & ?gnd18 : (k06,l10,e09,c04) , ? & ?vdd18 : (k05,k09,e10,e06) , ? & ?vdd33 : (l03,k08,k10,d12,e05) ? ; attribute tap_scan_clock of tck_pin : signal is (1.00e+07, both); attribute tap_scan_mode of tms_bkpt_pin : signal is true; attribute tap_scan_in of tdi_dsi_pin : signal is true; attribute tap_scan_out of tdo_dso_pin : signal is true; attribute tap_scan_reset of trst_dsclk_pin : signal is true; -- compilance pattern (forced value is required for correct -- -- jtag operation) -- -- * specified pins are not allowd to by part of the bsr -- attribute compliance_patterns of xcf5249: entity is ?(test3_pin, test2_pin, test1_pin, test0_pin, hiz_b_pin) (00001)?; attribute instruction_length of xcf5249 : entity is 4; mcf5249 bsdl file motorola section 20 ieee 1149.1 test access port (jtag) 20-17 attribute instruction_opcode of xcf5249 : entity is ?extest (0000),? & -- required by standard ?idcode (0001),? & -- required by standard ?sample (0010),? & -- required by standard ?highz (0100),? & -- optional instruction) ?ringosc (0111),? & -- privat instruction ?orgate (1000),? & -- privat instruction ?bypass (1111)? ; -- required by standard -- instruction loaded during capture ir state -- -- * least signigficant bits must be ?01? -- attribute instruction_capture of xcf5249 : entity is ?0001?; -- privat instruction: privat and potential unsave to use -- -- by others than the manufacturer -- attribute instruction_private of xcf5249 : entity is ?ringosc,? & ?orgate? ; attribute idcode_register of xcf5249 : entity is ?0010? & -- version number ?010101? & -- part number (part 1 (design center)) ?0000000110? & -- part number (part 2 (chip id)) ?00000001110? & -- manufacturer id ?1? ; -- required by standard -- bsr specification (?0? is the ce ll closest to tdo -- attribute boundary_length of xcf5249: entity is 242; attribute boundary_register of xcf5249: entity is -- num cell port function safe [ccell disval rslt ] ?0 (bc_2, *, control, 0 ) ,? & ?1 (bc_7, dbdcpst0_gp59_pin, bidir, x, 0, 0, z ) ,? & ?2 (bc_2, *, control, 0 ) ,? & ?3 (bc_7, dbdcpst2_gp61_pin, bidir, x, 2, 0, z ) ,? & ?4 (bc_2, *, control, 0 ) ,? & ?5 (bc_7, dbdcpst1_gp60_pin, bidir, x, 4, 0, z ) ,? & ?6 (bc_2, *, control, 0 ) ,? & ?7 (bc_2, cnpstclk_gp63_pin, output3, x, 6, 0, z ) ,? & ?8 (bc_2, *, control, 0 ) ,? & ?9 (bc_7, dbdcpst3_gp62_pin, bidir, x, 8, 0, z ) ,? & ?10 (bc_2, *, control, 0 ) ,? & ?11 (bc_7, rck_gp51_pin, bidir, x, 10, 0, z ) ,? & ?12 (bc_2, *, control, 0 ) ,? & ?13 (bc_2, rw_b_pin, output3, x, 12, 0, z ) ,? & ?14 (bc_2, *, control, 0 ) ,? & ?15 (bc_7, sfsy_gp52_pin, bidir, x, 14, 0, z ) ,? & ?16 (bc_2, *, control, 0 ) ,? & ?17 (bc_2, xtrim_gpo38_pin, output3, x, 16, 0, z ) ,? & ?18 (bc_2, *, control, 0 ) ,? & ?19 (bc_2, cl16_gpo42_pin, output3, x, 18, 0, z ) ,? & ?20 (bc_2, *, control, 0 ) ,? & ?21 (bc_7, subr_gp53_pin, bidir, x, 20, 0, z ) ,? & 20-18 mcf5249um motorola mcf5249 bsdl file ?22 (bc_2, *, control, 0 ) ,? & ?23 (bc_2, cl11_gpo39_pin, output3, x, 22, 0, z ) ,? & ?24 (bc_2, *, control, 0 ) ,? & ?25 (bc_7, iordy_gp16_pin, bidir, x, 24, 0, z ) ,? & ?26 (bc_2, *, control, 0 ) ,? & ?27 (bc_7, idedior_gp13_pin, bidir, x, 26, 0, z ) ,? & ?28 (bc_4, crin_pin, clock, x ) ,? & ?29 (bc_2, *, control, 0 ) ,? & ?30 (bc_7, idediow_gp14_pin, bidir, x, 29, 0, z ) ,? & ?31 (bc_4, ebuin1_gpi36_pin, input, x ) ,? & ?32 (bc_4, sdatai1_pin, input, x ) ,? & ?33 (bc_2, *, control, 0 ) ,? & ?34 (bc_7, ta_gp20_pin, bidir, x, 33, 0, z ) ,? & ?35 (bc_2, *, control, 0 ) ,? & ?36 (bc_7, sclk4_gp50_pin, bidir, x, 35, 0, z ) ,? & ?37 (bc_2, *, control, 0 ) ,? & ?38 (bc_7, sclk1_pin, bidir, x, 37, 0, z ) ,? & ?39 (bc_4, sdatai4_gpi42_pin, input, x ) ,? & ?40 (bc_2, *, control, 0 ) ,? & ?41 (bc_7, lrck4_gp46_pin, bidir, x, 40, 0, z ) ,? & ?42 (bc_2, *, control, 0 ) ,? & ?43 (bc_7, lrck1_pin, bidir, x, 42, 0, z ) ,? & ?44 (bc_2, *, control, 0 ) ,? & ?45 (bc_7, sdatao1_gp25_pin, bidir, x, 44, 0, z ) ,? & ?46 (bc_2, *, control, 0 ) ,? & ?47 (bc_7, bufenb2_gp17_pin, bidir, x, 46, 0, z ) ,? & ?48 (bc_2, *, control, 0 ) ,? & ?49 (bc_7, sclk2_gp48_pin, bidir, x, 48, 0, z ) ,? & ?50 (bc_2, *, control, 0 ) ,? & ?51 (bc_2, sdatao2_gpo41_pin, output3, x, 50, 0, z ) ,? & ?52 (bc_2, *, control, 0 ) ,? & ?53 (bc_7, sda2_gp55_pin, bidir, x, 52, 0, z ) ,? & ?54 (bc_2, *, control, 0 ) ,? & ?55 (bc_2, oe_pin, output3, x, 54, 0, z ) ,? & ?56 (bc_2, *, control, 0 ) ,? & ?57 (bc_7, lrck2_gp44_pin, bidir, x, 56, 0, z ) ,? & ?58 (bc_2, *, control, 0 ) ,? & ?59 (bc_2, tout1_gpo35_pin, output3, x, 58, 0, z ) ,? & ?60 (bc_4, rsti_pin, input, x ) ,? & ?61 (bc_2, *, control, 0 ) ,? & ?62 (bc_7, scl2_gp3_pin, bidir, x, 61, 0, z ) ,? & ?63 (bc_4, ebuin2_gpi37_pin, input, x ) ,? & ?64 (bc_4, ebuin3_adin0_gpi38_pin, input, x ) ,? & ?65 (bc_2, *, control, 0 ) ,? & ?66 (bc_2, ebuout1_gpo36_pin, output3, x, 65, 0, z ) ,? & ?67 (bc_2, *, control, 0 ) ,? & ?68 (bc_7, cflg_gp18_pin, bidir, x, 67, 0, z ) ,? & ?69 (bc_2, *, control, 0 ) ,? & ?70 (bc_2, ebuout2_gpo37_pin, output3, x, 69, 0, z ) ,? & ?71 (bc_2, *, control, 0 ) ,? & ?72 (bc_7, sdramcs2_gp7_pin, bidir, x, 71, 0, z ) ,? & ?73 (bc_2, *, control, 0 ) ,? & ?74 (bc_7, data16_pin, bidir, x, 73, 0, z ) ,? & ?75 (bc_2, *, control, 0 ) ,? & mcf5249 bsdl file motorola section 20 ieee 1149.1 test access port (jtag) 20-19 ?76 (bc_7, qspics3_gp22_pin, bidir, x, 75, 0, z ) ,? & ?77 (bc_2, *, control, 0 ) ,? & ?78 (bc_7, data17_pin, bidir, x, 77, 0, z ) ,? & ?79 (bc_2, *, control, 0 ) ,? & ?80 (bc_7, data23_pin, bidir, x, 79, 0, z ) ,? & ?81 (bc_2, *, control, 0 ) ,? & ?82 (bc_7, data18_pin, bidir, x, 81, 0, z ) ,? & ?83 (bc_2, *, control, 0 ) ,? & ?84 (bc_7, data22_pin, bidir, x, 83, 0, z ) ,? & ?85 (bc_2, *, control, 0 ) ,? & ?86 (bc_7, data20_pin, bidir, x, 85, 0, z ) ,? & ?87 (bc_2, *, control, 0 ) ,? & ?88 (bc_7, qspics2_gp21_pin, bidir, x, 87, 0, z ) ,? & ?89 (bc_2, *, control, 0 ) ,? & ?90 (bc_7, data19_pin, bidir, x, 89, 0, z ) ,? & ?91 (bc_2, *, control, 0 ) ,? & ?92 (bc_7, data21_pin, bidir, x, 91, 0, z ) ,? & ?93 (bc_2, *, control, 0 ) ,? & ?94 (bc_7, gp6_pin, bidir, x, 93, 0, z ) ,? & ?95 (bc_2, *, control, 0 ) ,? & ?96 (bc_7, qspidout_gp26_pin, bidir, x, 95, 0, z ) ,? & ?97 (bc_2, *, control, 0 ) ,? & ?98 (bc_7, qspics0_gp29_pin, bidir, x, 97, 0, z ) ,? & ?99 (bc_2, *, control, 0 ) ,? & ?100 (bc_7, gp5_pin, bidir, x, 99, 0, z ) ,? & ?101 (bc_2, *, control, 0 ) ,? & ?102 (bc_2, sdldqm_pin, output3, x, 101, 0, z ) ,? & ?103 (bc_2, *, control, 0 ) ,? & ?104 (bc_2, sdwe_pin, output3, x, 103, 0, z ) ,? & ?105 (bc_2, *, control, 0 ) ,? & ?106 (bc_2, sdcas_pin, output3, x, 105, 0, z ) ,? & ?107 (bc_2, *, control, 0 ) ,? & ?108 (bc_2, sdras_pin, output3, x, 107, 0, z ) ,? & ?109 (bc_2, *, control, 0 ) ,? & ?110 (bc_7, sdata1bs1_gp9_pin, bidir, x, 109, 0, z ) ,? & ?111 (bc_2, *, control, 0 ) ,? & ?112 (bc_2, sdramcs1_pin, output3, x, 111, 0, z ) ,? & ?113 (bc_2, *, control, 0 ) ,? & ?114 (bc_7, qspics1_gp24_pin, bidir, x, 113, 0, z ) ,? & ?115 (bc_2, *, control, 0 ) ,? & ?116 (bc_2, a20_pin, output3, x, 115, 0, z ) ,? & ?117 (bc_2, *, control, 0 ) ,? & ?118 (bc_2, a19_pin, output3, x, 117, 0, z ) ,? & ?119 (bc_2, *, control, 0 ) ,? & ?120 (bc_2, a16_pin, output3, x, 119, 0, z ) ,? & ?121 (bc_2, *, control, 0 ) ,? & ?122 (bc_2, a15_pin, output3, x, 121, 0, z ) ,? & ?123 (bc_2, *, control, 0 ) ,? & ?124 (bc_2, a14_pin, output3, x, 123, 0, z ) ,? & ?125 (bc_2, *, control, 0 ) ,? & ?126 (bc_2, a23_pin, output3, x, 125, 0, z ) ,? & ?127 (bc_2, *, control, 0 ) ,? & ?128 (bc_2, a25_gpo8_pin, output3, x, 127, 0, z ) ,? & ?129 (bc_2, *, control, 0 ) ,? & 20-20 mcf5249um motorola mcf5249 bsdl file ?130 (bc_2, a13_pin, output3, x, 129, 0, z ) ,? & ?131 (bc_2, *, control, 0 ) ,? & ?132 (bc_7, data31_pin, bidir, x, 131, 0, z ) ,? & ?133 (bc_2, *, control, 0 ) ,? & ?134 (bc_7, bufenb1_gp57_pin, bidir, x, 133, 0, z ) ,? & ?135 (bc_2, *, control, 0 ) ,? & ?136 (bc_7, data30_pin, bidir, x, 135, 0, z ) ,? & ?137 (bc_2, *, control, 0 ) ,? & ?138 (bc_7, sdata3_gp56_pin, bidir, x, 137, 0, z ) ,? & ?139 (bc_2, *, control, 0 ) ,? & ?140 (bc_7, data29_pin, bidir, x, 139, 0, z ) ,? & ?141 (bc_2, *, control, 0 ) ,? & ?142 (bc_7, data28_pin, bidir, x, 141, 0, z ) ,? & ?143 (bc_2, *, control, 0 ) ,? & ?144 (bc_7, data27_pin, bidir, x, 143, 0, z ) ,? & ?145 (bc_2, *, control, 0 ) ,? & ?146 (bc_7, sdata2bs2_rsto_pin, bidir, x, 145, 0, z ) ,? & ?147 (bc_2, *, control, 0 ) ,? & ?148 (bc_7, data26_pin, bidir, x, 147, 0, z ) ,? & ?149 (bc_2, *, control, 0 ) ,? & ?150 (bc_7, data25_pin, bidir, x, 149, 0, z ) ,? & ?151 (bc_2, *, control, 0 ) ,? & ?152 (bc_7, sdata0sdio1_gp54_pin, bidir, x, 151, 0, z ) ,? & ?153 (bc_2, *, control, 0 ) ,? & ?154 (bc_7, ef_gp19_pin, bidir, x, 153, 0, z ) ,? & ?155 (bc_2, *, control, 0 ) ,? & ?156 (bc_2, sdudqm_pin, output3, x, 155, 0, z ) ,? & ?157 (bc_2, *, control, 0 ) ,? & ?158 (bc_2, a22_pin, output3, x, 157, 0, z ) ,? & ?159 (bc_2, *, control, 0 ) ,? & ?160 (bc_7, data24_pin, bidir, x, 159, 0, z ) ,? & ?161 (bc_2, *, control, 0 ) ,? & ?162 (bc_7, sda_qspidin_pin, bidir, x, 161, 0, z ) ,? & ?163 (bc_2, *, control, 0 ) ,? & ?164 (bc_2, bclke_pin, output3, x, 163, 0, z ) ,? & ?165 (bc_2, *, control, 0 ) ,? & ?166 (bc_7, sclkout_gp15_pin, bidir, x, 165, 0, z ) ,? & ?167 (bc_2, *, control, 0 ) ,? & ?168 (bc_7, bclk_gp10_pin, bidir, x, 167, 0, z ) ,? & ?169 (bc_2, *, control, 0 ) ,? & ?170 (bc_2, a17_pin, output3, x, 169, 0, z ) ,? & ?171 (bc_2, *, control, 0 ) ,? & ?172 (bc_2, a18_pin, output3, x, 171, 0, z ) ,? & ?173 (bc_2, *, control, 0 ) ,? & ?174 (bc_7, cmdsdio2_gp34_pin, bidir, x, 173, 0, z ) ,? & ?175 (bc_2, *, control, 0 ) ,? & ?176 (bc_2, a9_pin, output3, x, 175, 0, z ) ,? & ?177 (bc_2, *, control, 0 ) ,? & ?178 (bc_2, a10_pin, output3, x, 177, 0, z ) ,? & ?179 (bc_2, *, control, 0 ) ,? & ?180 (bc_2, a11_pin, output3, x, 179, 0, z ) ,? & ?181 (bc_2, *, control, 0 ) ,? & ?182 (bc_2, a21_pin, output3, x, 181, 0, z ) ,? & ?183 (bc_2, *, control, 0 ) ,? & mcf5249 bsdl file motorola section 20 ieee 1149.1 test access port (jtag) 20-21 ?184 (bc_2, cs0_pin, output3, x, 183, 0, z ) ,? & ?185 (bc_2, *, control, 0 ) ,? & ?186 (bc_7, scl_qspiclk_pin, bidir, x, 185, 0, z ) ,? & ?187 (bc_2, *, control, 0 ) ,? & ?188 (bc_2, a12_pin, output3, x, 187, 0, z ) ,? & ?189 (bc_2, *, control, 0 ) ,? & ?190 (bc_2, a7_pin, output3, x, 189, 0, z ) ,? & ?191 (bc_2, *, control, 0 ) ,? & ?192 (bc_2, a8_pin, output3, x, 191, 0, z ) ,? & ?193 (bc_2, *, control, 0 ) ,? & ?194 (bc_2, a5_pin, output3, x, 193, 0, z ) ,? & ?195 (bc_2, *, control, 0 ) ,? & ?196 (bc_2, a6_pin, output3, x, 195, 0, z ) ,? & ?197 (bc_2, *, control, 0 ) ,? & ?198 (bc_2, a4_pin, output3, x, 197, 0, z ) ,? & ?199 (bc_2, *, control, 0 ) ,? & ?200 (bc_2, a3_pin, output3, x, 199, 0, z ) ,? & ?201 (bc_2, *, control, 0 ) ,? & ?202 (bc_2, a2_pin, output3, x, 201, 0, z ) ,? & ?203 (bc_2, *, control, 0 ) ,? & ?204 (bc_7, tin1_gp23_pin, bidir, x, 203, 0, z ) ,? & ?205 (bc_2, *, control, 0 ) ,? & ?206 (bc_2, a1_pin, output3, x, 205, 0, z ) ,? & ?207 (bc_2, *, control, 0 ) ,? & ?208 (bc_7, cs1_gp58_pin, bidir, x, 207, 0, z ) ,? & ?209 (bc_4, rxd1_gpi27_pin, input, x ) ,? & ?210 (bc_2, *, control, 0 ) ,? & ?211 (bc_7, sclk3_gp49_pin, bidir, x, 210, 0, z ) ,? & ?212 (bc_2, *, control, 0 ) ,? & ?213 (bc_2, txd1_gpo27_pin, output3, x, 212, 0, z ) ,? & ?214 (bc_2, *, control, 0 ) ,? & ?215 (bc_7, swe_gp12_pin, bidir, x, 214, 0, z ) ,? & ?216 (bc_2, *, control, 0 ) ,? & ?217 (bc_7, lrck3_gp45_pin, bidir, x, 216, 0, z ) ,? & ?218 (bc_2, *, control, 0 ) ,? & ?219 (bc_7, sre_gp11_pin, bidir, x, 218, 0, z ) ,? & ?220 (bc_4, ebuin4_adin1_gpi39_pin, input, x ) ,? & ?221 (bc_2, *, control, 0 ) ,? & ?222 (bc_2, rts1_gpo30_pin, output3, x, 221, 0, z ) ,? & ?223 (bc_2, *, control, 0 ) ,? & ?224 (bc_2, txd2_gpo28_pin, output3, x, 223, 0, z ) ,? & ?225 (bc_4, cts1_gpi30_pin, input, x ) ,? & ?226 (bc_4, sdatai3_gpi41_pin, input, x ) ,? & ?227 (bc_2, *, control, 0 ) ,? & ?228 (bc_2, rts2_gpo31_pin, output3, x, 227, 0, z ) ,? & ?229 (bc_4, rxd2_adin2_gpi28_pin, input, x ) ,? & ?230 (bc_2, *, control, 0 ) ,? & ?231 (bc_7, dbdcddata0_gp0_pin, bidir, x, 230, 0, z ) ,? & ?232 (bc_4, cts2_adin3_gpi31_pin, input, x ) ,? & ?233 (bc_2, *, control, 0 ) ,? & ?234 (bc_7, dbdcddata2_gp2_pin, bidir, x, 233, 0, z ) ,? & ?235 (bc_2, *, control, 0 ) ,? & ?236 (bc_7, dbdcddata1_gp1_pin, bidir, x, 235, 0, z ) ,? & ?237 (bc_2, *, control, 0 ) ,? & 20-22 mcf5249um motorola obtaining the ieee 1149.1a standard ?238 (bc_2, tout0_gpo33_pin, output3, x, 237, 0, z ) ,? & ?239 (bc_2, *, control, 0 ) ,? & ?240 (bc_7, dbdcddata3_gp4_pin, bidir, x, 239, 0, z ) ,? & ?241 (bc_4, tin0_gpi33_pin, input, x ) ? ; end xcf5249; 20.8 obtaining the ieee 1149.1a standard the ieee 1149 standard jtag specification is a copyrighted document and must be obtained directly from the ieee: ieee standards department 445 hoes lane p.o. box 1331 piscataway, nj 08855-1331 usa http://stdsbbs.ieee.org/ fax: 908-981-9667 information: 908-981-0060 or 1-800-678-4333 motorola section 21 electrical specifications 21-1 section 21 electrical specifications 1. this published maximum operating ambient temperature should be used only as a system design guideline. all device operating parameters are guaranteed only when t he junction temperature does not exceed 105 c. table 21-1 maximum ratings rating symbol value units supply core voltage v cc -0.5 to +2.5 v maximum core operating voltage v cc +1.98 v minimum core operating voltage v cc +1.62 v supply i/o voltage v cc -0.5 to +4.6 v maximum i/o operating voltage v cc +3.6 v minimum i/o operating voltage v cc +3.0 v input voltage v in -0.5 to +6.0 v storage temperature range t stg -65 to150 o c table 21-2 operating temperature characteristic symbol value units maximum operating ambient temperature t amax 85 1 c minimum operating ambient temperature t amin 0 o c 21-2 mcf5249um motorola 1. data[31:16], addr[25,23:9], pstclk, sclk 2. scl, sda, pst[3:0], ddata[3:0], tdso, sdras , sdcas , sdwe , sdramcs [2:1], sdldqm , sdudqm, r/w 3. tout[1:0], rts[2:1], txd[2:1], sclk[4:1] 4. bkpt /tms, dsi/tdi, dsclk/trst 5. capacitance c in is periodically sampled rather than 100% tested. 6. sclk[4:1], scl, scl2, sda, sda2, crin, rsti table 21-3 dc electrical specifications (vcc = 3.3 vdc + 0.3 vdc) characteristic symbol min max units operation voltage range v cc 3.0 3.6 v input high voltage v ih 25.5 v input low voltage v il -0.3 0.8 v input leakage current @ 0.0v /3.3 v during normal operation i in - 1 a hi-impedance (three-state) leakage current @ 0.0v/3.3 v during normal operation i tsi - 1 a output high voltage i oh = 8ma 1 , 4ma 2 , 2ma 3 v oh 2.4 - v output low voltage i ol = 8ma 1 , 4ma 2 , 2ma 3 v ol -0.4 v schmitt trigger low to high threshold point 6 v t+ 1.47 - v schmitt trigger high to low threshold point 6 v t- -.95 v load capacitance (data[31:16], dcl0, dcl1, sclk[4:1], sclkout, ebuout[2:1], lrck[4:1], sdatao[2:1], cflg, ef, dbcddata[3:0], dbdcpst[3:0], cnpstclk, idedior, idediow, iordy, sre, swe) c l -50 pf load capacitance (addr[25,23:9], sclk) c l -40 pf load capacitance (bclke, sdcas, sdras, sdldqm, sdramcs[2:1], sdudqm, sdwe, bufenb[2:1]) c l -30 pf load capacitance (sda, sda2, scl, scl2, cmdsdio2, sdata2bs2, sdata1bs1, sdata0sdio1, cs[1:0], oe, r/w , ta, txd[2:1], xtrim, tdo/dso, rck, sfsy, subr, sdata3, tout[1:0], qspidout, qspics[3:0], gp[6:5]) c l -20 pf capacitance 5 , v in = 0 v, f = 1 mhz c in -6 pf motorola section 21 electrical specifications 21-3 note: the following signals are not available on the 144 qfp package. table 21-4 160 mapbga ball assignments 160mapbga ball number function gpio e3 cmd_sdio2 gpio34 g4 sdata0_sdio1 gpio54 h3 rsto/sdata2_bs2 k3 a25 gpo8 l4 qspi_cs1 gpio24 l8 qspi_cs3 gpio22 n8 sdram_cs2 gpio7 p9 ebuout2 gpo 37 k11 bufenb2 gpio17 g12 subr gpio 53 f13 sfsy gpio 52 f12 rck gpio 51 e8 sre gpio11 b8 lrck3 gpio 45 e7 swe gpio12 a7 sclk3 gpio 49 21-4 mcf5249um motorola 1 there are only three choices for the valid audio frequencies 11.29 mhz, 16.93 mhz, or 33.86 mhz; no other values are allowed. the system clock is derived from one of these crystals via an internal pll. figure 21-1 clock timing definition note: signals above are shown in relation to the clock. no relationship between signals is implied or intended. table 21-5 clock timing specification num characteristic units min max crin frequency 1 11.29 33.86 mhz c5 pstclk cycle time 7.1 ? nsec c6 pstclk duty cycle 40 60 % c7 sclk cycle time 14.2 ? nsec c8 sclk duty cycle 45 55 % crin pstclk sclk c6 c6 c7 c8 c8 motorola section 21 electrical specifications 21-5 1. inputs (rising): data[31:16] 2. ac timing specs assume 40pf load capacitance on sclk and 50pf load capacitance on output pins. if this value is different, the input and output timing specifications would need to be adjusted to match the clock load. 1. outputs (8ma): data[31:16], addr[25,23:9] 2. outputs (4ma): sdras, sdcas, sdwe, sdramcs[2:1], sdudqm, sdldqm, bclke 3. high impedance (three-state): data[31:16] 4. ac timing specs assume 40pf load capacitance on sclk and a 50pf load capacitance on output pins. if this value is different, the input and output timing specifications would need to be adjusted to match the clock load. table 21-6 input ac timing specification num characteristic units min max b1 1,2 signal valid to sclk rising (setup) 3 ? nsec b2 1 sclk rising to signal invalid (hold) 2 ? nsec b3 1 sclk to input high impedance ? 5 sclk cycle table 21-7 output ac timing specification num characteristic 5 units min max b10 1 sclk (8ma) rising to signal valid --- 10 nsec b11 1 sclk (8ma) rising to signal invalid (hold) 3.5 ? nsec b10 2 sclk (4ma) rising to signal valid --- 11 nsec b11 2 sclk (4ma) rising to signal invalid (hold) 4 ? nsec b12 3 sclk to high impedance (three-state) --- 14 nsec h1 hiz to high impedance ? tbd nsec h2 hiz to low impedance ? tbd nsec 21-6 mcf5249um motorola figure 21-2 input/output timing definition-i sclk addr[23:0] r/w data[31:16] b10 b2 b5 b10 b11 b12 s0 s1 s2 s3 s4 s5 s0 s1 s2 s3 s4 s5 motorola section 21 electrical specifications 21-7 figure 21-3 input/output timing definition-iii b13 b14 sclk h1 h2 hiz outputs outputs sclk b3 b4 inputs 21-8 mcf5249um motorola 1. dsclk and dsi are internally synchroni zed. this setup time must be met only if recognition on a particular clock is required. 2. ac timing specs assume 50pf load capacitance on pstclk and output pins. if this value is different, the input and output timing specifications would need to be adjusted to match the clock load. figure 21-4 debug timing definition table 21-8 debug ac timing specification num characteristic units min max d1 pstclk to signal valid (output valid) --- 6 nsec d2 pstclk to signal invalid (output hold) 1.8 ? nsec d3 1 signal valid to pstclk (input setup) 3 ? nsec d4 pstclk to signal invalid (input hold) 5 ? nsec pstclk dsclk dsi pst[3:0] ddata[3:0] dso d3 d1 d2 d3 d4 d4 motorola section 21 electrical specifications 21-9 figure 21-5 timer module timing definition table 21-9 timer module ac timing specification num characteristic units min max t1 tin cycle time tbd ? bus clocks t2 tin valid to sclk (input setup) tbd ? nsec t3 sclk to tin invalid (input hold) tbd ? nsec t4 sclk to tout valid (output valid) ? tbd nsec t5 sclk to tout invalid (output hold) tbd ? nsec t6 tin pulse width tbd ? bus clocks t7 tout pulse width tbd ? bus clocks sclk t6 t2 t3 t1 t7 t4 t5 tin tin tout 21-10 mcf5249um motorola figure 21-6 uart timing definition table 21-10 uart module ac timing specifications num characteristic units min max u1 rxd valid to sclk (input setup) tbd ? nsec u2 sclk to rxd invalid (input hold) tbd ? nsec u3 cts valid to sclk (input setup) tbd ? nsec u4 sclk to cts invalid (input hold) tbd ? nsec u5 sclk to txd valid (output valid) --- tbd nsec u6 sclk to txd invalid (output hold) tbd ? nsec u7 sclk to rts valid (output valid) --- tbd nsec u8 sclk to rts invalid (output hold) tbd ? nsec sclk rxd cts txd rts u1 u2 u3 u4 u5 u6 u7 u8 motorola section 21 electrical specifications 21-11 1. note: output numbers are dependent on the value programmed into the mfdr; an mfdr programmed with the maximum frequency (mfdr = 0x20) will result in minimum output timings as shown in the above table. the mbus interface is designed to scale the actual data transition time to move it to the middle of the scl low period. the actual table 21-11 i 2 c-bus input timing specifications between scl and sda num characteristic units min max m1 start condition hold time tbd ? bus clocks m2 clock low period tbd ? bus clocks m3 scl/sda rise time (vil= 0.5 v to vih = 2.4 v) ? tbd msec m4 data hold time tbd ? nsec m5 scl/sda fall time (vih= 2.4 v to vil = 0.5 v) ? tbd msec m6 clock high time tbd ? bus clocks m7 data setup time tbd ? nsec m8 start condition setup time (for repeated start condition only) tbd ? bus clocks m9 stop condition setup time tbd ? bus clocks table 21-12 i 2 c-bus output timing specifications between scl and sda num characteristic units min max m1 1 start condition hold time tbd ? bus clocks m2 1 clock low period tbd ? bus clocks m3 2 scl/sda rise time (v il = 0.5 v to v ih = 2.4 v) ?tbd msec m4 1 data hold time tbd ? bus clocks m5 3 scl/sda fall time (v ih = 2.4 v to v il = 0.5 v) ? tbd nsec m6 1 clock high time tbd ? bus clocks m7 1 data setup time tbd ? bus clocks m8 1 start condition setup time (for repeated start condition only) tbd ? bus clocks m9 1 stop condition setup time tbd ? bus clocks 21-12 mcf5249um motorola position is affected by the prescale and division values programmed into the mfdr; however, numbers given in the above table are the minimum values. 2. since scl and sda are open-collector-type outputs, which the pr ocessor can only actively drive low, the time required for scl or sda to reach a high level depends on exte rnal signal capacitance and pull-up resistor values. 3. specified at a nominal 20 pf load figure 21-7 i 2 c timing definition 1. since scl and sda are open-collector-type outputs, which the pr ocessor can only actively driv e low, this specification applies only when scl or sda are driven low by the processor. the time required for scl or sda to reach a high level depends on external signal capacitanc e and pull-up resistor values. 2. since scl and sda are open-collector-type outputs, which the pr ocessor can only actively drive low, this specification applies only when scl or sda are actively being driven or held low by the processor. 3. scl and sda are internally synchronized.this setup time must be met only if recognition on a particular clock is required. table 21-13 num characteristic 96 mhz units min max m10 3 scl, sda valid to sclk (input setup) tbd ? nsec m11 sclk to scl, sda invalid (input hold) tbd ? nsec m12 1 sclk to scl, sda low (output valid) ? tbd nsec m13 2 sclk to scl, sda invalid (output hold) tbd ? nsec m2 m6 m1 m4 m7 m8 m9 m5 m3 s cl s da motorola section 21 electrical specifications 21-13 figure 21-8 i 2 c and system clock timing relationship figure 21-9 general-purpose parallel port timing definition table 21-14 general-purpose i/o port ac timing specifications num characteristic units min max p1 gpio valid to sclk (input setup) tbd ? nsec p2 sclk to gpio invalid (input hold) tbd ? nsec p3 sclk to gpio valid (output valid) ? tbd nsec p4 sclk to gpio invalid (output hold) tbd ? nsec sclk scl, sda in scl, sda out scl, sda out m10 m11 m12 m13 sclk gpio in gpio out p1 p2 p4 p3 21-14 mcf5249um motorola table 21-15 ieee 1149.1 (jtag) ac timing specifications num characteristic units min max - tck frequency of operation 0 10 mhz j1 tck cycle time 100 - nsec j2a tck clock pulse high width 25 - nsec j2b tck clock pulse low width 25 - nsec j3a tck fall time (v ih =2.4 v to v il =0.5v) ? 5 nsec j3b tck rise time (v il =0.5v to v ih =2.4v) ? 5 nsec j4 tdi, tms to tck rising (input setup) 8 ? nsec j5 tck rising to tdi, tms invalid (hold) 10 ? nsec j6 boundary scan data valid to tck (setup) tbd ? nsec j7 tck to boundary scan data invalid to rising edge (hold) tbd ? nsec j8 trst pulse width (asynchronous to clock edges) 12 ? nsec j9 tck falling to tdo valid (signal from driven or three-state) ?15nsec j10 tck falling to tdo high impedance ? 15 nsec j11 tck falling to boundary scan data valid (signal from driven or three-state) ? tbd nsec j12 tck falling to boundary scan data high impedance ? tbd nsec motorola section 21 electrical specifications 21-15 figure 21-10 j1 j2a j2b j4 j5 j6 j7 j8 j9 j10 j11 j12 j3a j3b tck tdi, tms trst tdo boundary scan data output boundary scan data input 21-16 mcf5249um motorola jtag timing definition iis module ac timing specifications 21.1 jtag timing definiti on iis module ac timing specifications figure 21-11 sclk input, sdata output timing figure 21-12 sclk output, sdatao output timing diagram table 21-16 sclk input, sdatao output timing specifications name characteristic unit min max tu sclk fall to sdatao rise --- 25 ns td sclk fall to sdatao fall --- 25 ns table 21-17 sclk output, sdata0 output timing specifications name characteristic unit min max tu sclk fall to sdatao rise --- 3 ns td sclk fall to sdatao fall --- 3 ns sclk (input) sdatao1, 2 (output) tu td sclk (output) sdatao1, 2 (output) tu td jtag timing definition iis module ac timing specifications motorola section 21 electrical specifications 21-17 figure 21-13 sclk input/output, sdatai input timing diagram table 21-18 sclk input, sdatai input timing specifications name characteristic unit min max tsu sdatai in to sclkn -5 ? ns th sclk rise to sdatai 3 ? ns sclk sdata1, 3, 4 (input) tsu th ( inp ut or output ) 21-18 mcf5249um motorola notes motorola section 22 mechanical data 22-1 section 22 mechanical data visit the url [http://www.motorola.com/coldfire] and choose the documentation library to obtain information on the mechanical characteristics of the mcf5249 integrated microprocessor. 22.1 package the mcf5249 can be assembled in either a 160-pin map bga or 144-pin qfp package. thermal characteristics are not available at this time. 22.2 pin assignment the mcf5249 is available in 160 pin mapbga package and 144 pin qfp package options. 22-2 mcf5249um motorola pin assignment table 22-1 144 qfp pin assignments 144 qfp pin number name type description 1 scl/qspi_clk i/o iic clock/qspi clock pin function select is pllcr(11) 2 cs0 o static chip select 0 3 a21 o sdram address / static adr 4 a11 o sdram address / static adr 5 a10 o sdram address / static adr 6 a9 o sdram address / static adr 7 a18 o sdram address / static adr 8 a17 o sdram address / static adr 9 bclk/gpio10 i/o sdram clock output 10 sclk_out/gpio15 i/o memorystick/sd 11 bclke o sdram clock enable output 12 sda/qspi_din i/o iic data/qspi data in function select is pllcr(11) 13 data24 i/o data 14 a22 o sdram address / static adr 15 sdudqm o sdram udqm 16 ef/gpio19 i/o error flag input 17 data25 i/o data 18 data26 i/o data 19 data27 i/o data 20 pad-gnd pad-gnd 21 data28 i/o data 22 data29 i/o data 23 sdata3/gpio56 i/o sd interface data line 24 data30 i/o data 25 bufenb1/gpio57 i/o external buffer 1 enable 26 data31 i/o data 27 core-vdd core-vdd 28 a13 o sdram address / static adr 29 core-gnd core-gnd 30 a23 o sdram address / static adr 31 a14 o sdram address / static adr 32 a15 o sdram address / static adr 33 a16 o sdram address / static adr 34 pad-vdd pad-vdd 35 a19 o sdram address / static adr 36 a20 o sdram address / static adr 37 test2 i test pin assignment motorola section 22 mechanical data 22-3 38 sdram_cs1 o sdram chip select out 1 39 sdata1_bs1/gpio9 i/o memory stick / sd 40 sdras o sdram ras 41 sdcas o sdram cas 42 sdwe o sdram write enable 43 sdldqm o sdram ldqm 44 gpio5 i/o gpio5 45 qspi_cs0/gpio29 i/o qspi chip select 0 46 qspi_dout/gpio26 i/o qspi data out 47 gpio6 i/o gpio6 48 data21 i/o data 49 data19 i/o data 50 qspi_cs2/gpio21 i/o qspi chip select 2 51 data20 i/o data 52 data22 i/o data 53 data18 i/o data 54 data23 i/o data 55 data17 i/o data 56 pad-vdd pad-vdd 57 data16 i/o data 58 cflg/gpio18 i/o cflg input 59 ebuout1/gpo36 o audio interfaces ebu out 1 60 core-gnd core-gnd 61 ebuin3/adin0/gpi38 i audio interfaces ebu in 3 / ad convertor input0 62 ebuin2/gpi37 i audio interfaces ebu in 2 63 core-vdd core-vdd 64 scl2/gpio3 i/o iis2 clock line 65 rsti i reset 66 tout1/adout/gpo35 o timer output 1 / ad output 67 lrck2/gpio44 o audio interfaces ebu out 1 68 oe o output enable 69 sda2/gpio55 i/o iis2 data 70 sdatao2/gpo41 o audio interfaces serial data output 2 71 sclk2/gpio48 i/o audio interfaces serial clock 2 72 pad-gnd pad-gnd 73 test3 i test 74 sdatao1/gpio25 i/o audio interfaces serial data output 1 75 lrck1 i/o audio interfaces word clock 1 76 lrck4/gpio46 i/o audio interfaces word clock 4 table 22-1 144 qfp pin assignments 144 qfp pin number name type description 22-4 mcf5249um motorola pin assignment 77 sdatai4/gpi42 i audio interfaces serial data in 4 78 sclk1 i/o audio interfaces serial clock 1 79 sclk4/gpio50 i/o audio interfaces serial clock 4 80 ta/gpio20 i/o transfer acknowledge 81 sdatai1 i audio interfaces serial data in 1 82 ebuin1/gpi36 i audio interfaces ebu in 1 83 pllgrdvdd pllgrdvdd 84 pllgrdgnd pllgrdgnd 85 pllpadgnd pllpadgnd 86 pllpadvdd pllpadvdd 87 pllcoregnd pllcoregnd 88 pllcorevdd pllcorevdd 89 ide-diow/gpio14 i/o ide diow 90 crin i crystal 91 ide-dior/gpio13 i/o ide dior 92 ide-iordy/gpio16 i/o ide iordy 93 mclk1/gpo39 o audio master clock output 1 94 mclk2/gpo42 o audio master clock output 2 95 xtrim/gpo38 o audio interfaces x-tal trim 96 trst/dsclk i jtag/debug 97 core-vdd core-vdd 98 rw_b o bus write enable 99 tms/bkpt i jtag/debug 100 core-gnd core-gnd 101 tck i jtag 102 pad-gnd pad-gnd 103 pst3/gpio62 i/o debug 104 cnpstclk/gpo63 o debug 105 pst1/gpio60 i/o debug 106 pad-vdd pad-vdd 107 pst2/gpio61 i/o debug 108 pst0/gpio59 i/o debug 109 tdi/dsi i jtag/debug 110 test0 i test 111 tin0/gpi33 i timer input 0 112 hi-z i jtag 113 ddata3/gpio4 i/o debug 114 tout0/gpo33 o timer output 0 115 ddata1/gpio1 i/o debug table 22-1 144 qfp pin assignments 144 qfp pin number name type description pin assignment motorola section 22 mechanical data 22-5 116 ddata2/gpio2 i/o debug 117 cts2_b/adin3/gpi31 i second uart clear to send / ad input 3 118 ddata0/gpio0 i/o debug 119 rxd2/gpi28/adin2 i second uart receive data input / ad input 2 120 tdso o jtag/debug 121 rts2_b/gpo31 o second uart request to send 122 sdatai3/gpi41 i audio interfaces serial data input 3 123 cts1_b/gpi30 i first uart clear to send 124 txd2/gpo28 o second uart transmit data output 125 rts1_b/gpo30 o first uart request to send 126 ebuin4/adin1/gpi39 i audio interf aces ebu input 4 / ad input 1 127 txd1/gpo27 o first uart transmit data output 128 rxd1/gpi27 i first uart receive data input 129 cs1/gpio58 i/o chip select 1 130 core-gnd core-gnd 131 a1 o sdram address / static adr 132 tin1/gpio23 i/o timer input 1 133 a2 o address 134 a3 o address 135 pad-gnd pad-gnd 136 a4 o address 137 a6 o address 138 a5 o address 139 a8 o address 140 a7 o address 141 core-vdd core-vdd 142 a12 o address 143 test1 i test 144 pad-vdd pad-vdd table 22-1 144 qfp pin assignments 144 qfp pin number name type description 22-6 mcf5249um motorola pin assignment the following pins are in the 160 pin mapbga package, but are not available in the 144 pin qfp package. table 22-2 160 mapbga pins 160 mapbga ball number function gpio e3 cmd_sdio2 gpio34 g4 sdata0_sdio1 gpio54 h3 rsto/sdata2_bs2 k3 a25 gpo8 l4 qspi_cs1 gpio24 l8 qspi_cs3 gpio22 n8 sdram_cs2 gpio7 p9 ebuout2 gpo 37 k11 bufenb2 gpio17 g12 subr gpio 53 f13 sfsy gpio 52 f12 rck gpio 51 e8 sre gpio11 b8 lrck3 gpio 45 e7 swe gpio12 a7 sclk3 gpio 49 pin assignment motorola section 22 mechanical data 22-7 table 22-3 160 mapbga pin assignments pin bga name typ e description d4 scl/qspi_clk i/o iic clock/qspi clock pin function select is pllcr(11) a1 cs0 o static chip select 0 d3 a21 o sdram address / static adr b1 a11 o sdram address / static adr c2 a10 o sdram address / static adr c1 a9 o sdram address / static adr e3 cmd_sdio2/gpio34 io memorystick/sd d2 a18 o sdram address / static adr d1 a17 o sdram address / static adr e2 bclk/gpio10 i/o sdram clock output f3 sclk_out/gpio15 i/o memorystick/sd e1 bclke o sdram clock enable output e4 sda/qspi_din i/o iic data/qspi da ta in function select is pllcr(11) f2 data24 i/o data bus bit 24 g3 a22 o sdram address / static adr f1 sdudqm o sdram udqm f4 ef/gpio19 io error flag input g4 sdata0_sdio1/gpio54 i/o memorystick/sd g1 data25 i/o data bus bit 25 g2 data26 i/o data bus bit 26 h3 rsto/sdata2_bs2 i/o reset output/memorystick/sd/ h1 data27 i/o data bus bit 27 h4 pad-gnd pad-gnd h4 pad-gnd pad-gnd h2 data28 i/o data bus bit 28 j1 data29 i/o data bus bit 29 j3 sdata3/gpio56 io sd interface data line j2 data30 i/o data bus bit 30 j4 bufenb1/gpio57 io external buffer 1 enable k1 data31 i/o data bus bit 31 k6 core-vdd core-vdd k6 core-vdd core-vdd k2 a13 o sdram address / static adr k3 a25/gpo8 o sdram address / static adr k5 core-gnd core-gnd k5 core-gnd core-gnd k4 a23 o sdram address / static adr l1 a14 o sdram address / static adr 22-8 mcf5249um motorola pin assignment l2 a15 o sdram address / static adr m1 a16 o sdram address / static adr l3 pad-vdd pad-vdd l3 pad-vdd pad-vdd m2 a19 o sdram address / static adr n1 a20 o sdram address / static adr l4 qspi_cs1/gpio24 io qspi select 1 m3 test2 i structural test n2 sdram_cs1 o sdram chip select out 1 m4 sdata1_bs1/gpio9 i/o memorystick/sd p1 sdras o sdram ras p2 sdcas o sdram cas n3 sdwe o sdram write enable p3 sdldqm o sdram ldqm n4 gpio5 i/o general purpose i/o p4 qspi_cs0/gpio29 i/o qspi chip select 0 n5 qspi_dout/gpio26 i/o qspsi data out l5 gpio6 i/o general purpose i/o p5 data21 i/o data bus bit 21 n6 data19 i/o data bus bit 19 l6 qspi_cs2/gpio21 i/o qspi chip select 2 p6 data20 i/o data bus bit 20 l7 data22 i/o data bus bit 22 p7 data18 i/o data bus bit 18 k7 data23 i/o data bus bit 23 n7 data17 i/o data bus bit 17 l8 qspi_cs3/gpio22 io qspi chip select 3 k8 pad-vdd pad-vdd k8 pad-vdd pad-vdd p8 data16 i/o data bus bit 16 n8 sdram_cs2 / gpio7 i/o sdram chip select out 2 gpo p9 ebuout2 / gpo 37 o audio interfaces ebu out 2 l9 cflg/gpio18 io cflg input n9 ebuout1 / gpo 36 o audio interfaces ebu out 1 k9 core-gnd core-gnd k9 core-gnd core-gnd p10 ebuin3 / adin0/gpi 38 i audio interfaces ebu in 3 a/d convertor input 0 n10 ebuin2 / gpi 37 i audio interfaces ebu in 2 table 22-3 160 mapbga pin assignments pin bga name typ e description pin assignment motorola section 22 mechanical data 22-9 l10 core-vdd core-vdd l10 core-vdd core-vdd p11 scl2/gpio3 i/o iic clock p12 rsti i reset input n11 tout1 / adout/gpo35 o timer output 1/ad output p13 lrck2 / gpio 44 io audio interfaces serial word clock 2 n12 oe o output enable m11 sda2/gpio55 i/o iic 2 data line p14 sdatao2 / gpo41 o audio interfaces serial data 2 out n13 sclk2 / gpio 48 io audio interfaces serial clock 2 k10 pad-gnd pad-gnd k10 pad-gnd pad-gnd k11 bufenb2/gpio17 io external buffer 2 enable m12 test3 i structural test l12 sdatao1/gpio25 io audio interfaces serial data 1 out n14 lrck1 io audio interfaces serial word clock 1 m13 lrck4 / gpio 46 io audio interfaces serial word clock 4 m14 sdatai4 / gpi 42 i audio interfaces serial data 4 in l13 sclk1 io audio interfaces serial clock 1 l14 sclk4 / gpio 50 io audio interfaces serial clock 4 l11 ta/gpio20 i/o transfer acknowledge k13 sdatai1 i audio interfaces serial data 1 in k12 ebuin1 / gpi 36 i audio interfaces ebu in 1 k14 pllgrdvdd io pll guard supply (1.8 v) j11 pllgrdgnd pll guard supply gnd j13 pllpadgnd 3.3 volt pll gnd j12 pllpadvdd 3.3 volt pll vdd j14 pllcoregnd 1.8 volt pll analog supply- gnd h11 pllcorevdd 1.8 volt pll analog supply - vdd h12 ide-diow/gpio14 io ide diow h14 crin i crystal h13 ide-dior/gpio13 io ide dior g11 ide-iordy/gpio16 i/o ide iordy g14 mclk1/gpo39 o audio master clock output 1 g12 subr / gpio 53 io subcode data g13 mclk2/gpo42 o audio master clock output 2 f14 xtrim/gpo 38 o audio interfaces x-tal trim f11 trst/dsclk i jtag f13 sfsy / gpio 52 io subcode sync table 22-3 160 mapbga pin assignments pin bga name typ e description 22-10 mcf5249um motorola pin assignment e9 core-vdd core-vdd e9 core-vdd core-vdd e14 rw_b o bus write enable f12 rck / gpio 51 io subcode clock e13 tms/bkpt i jtag e10 core-gnd core-gnd e10 core-gnd core-gnd e12 tck i jtag e11 pad-gnd pad-gnd e11 pad-gnd pad-gnd d14 pst3/gpio 62 io coldfire debug port d13 cnpstclk / gpo 63 o coldfire debug clock c14 pst1/gpio 60 io coldfire debug port d12 pad-vdd pad-vdd d12 pad-vdd pad-vdd c13 pst2/gpio 61 io coldfire debug port b14 pst0/gpio 59 io coldfire debug port d11 tdi/dsi i jtag c12 test0 i structural test b13 tin0 / gpi33 i timer input 0 c11 hi-z i jtag a14 ddata3/gpio 4 io coldfire debug port a13 tout0 / gpo33 o timer output 0 b12 ddata1/gpio 1 io coldfire debug port a12 ddata2/gpio 2 io coldfire debug port b11 cts2_b / adin3/gpi31 i second uart clear to send, ad input 3 a11 ddata0/gpio 0 io coldfire debug port b10 rxd2 / gpi28/adin2 i second uart receive data input ad input 2 d10 tdso o jtag a10 rts2_b / gpo31 o second uart request to send b9 sdatai3 / gpi 41 i audio interfaces serial data 3 in d9 cts1_b / gpi30 i first uart clear to send a9 txd2 / gpo28 o second uart transmit data output d8 rts1_b / gpo30 o first uart request to send a8 ebuin4 / adin1/gpi 39 i audio interfaces ebu in 4/ ad convertor input 1 e8 sre/gpio11 io smartmedia read enable b8 lrck3 / gpio 45 io audio interfaces serial word clock 3 e7 swe/gpio12 io smartmedia write enable table 22-3 160 mapbga pin assignments pin bga name typ e description pin assignment motorola section 22 mechanical data 22-11 d7 txd1 / gpo27 o first uart transmit data output a7 sclk3 / gpio 49 io audio interfaces serial clock 3 b7 rxd1 / gpi27 i first uart receive data input a6 cs1 / gpio58 io static chip select 1 / gpio 1 e6 core-gnd core-gnd e6 core-gnd core-gnd b6 a1 o static address a1 d6 tin1/gpio23 io timer 1 in a5 a2 o static address a2 b5 a3 o static address a3 d5 pad-gnd pad-gnd d5 pad-gnd pad-gnd a4 a4 o static adr 4 a3 a6 o static adr 6 b4 a5 o static adr 5 a2 a8 o static adr 8 b3 a7 o static adr 7 c4 core-vdd core-vdd c4 core-vdd core-vdd b2 a12 o sdram address / static adr c3 test1 i structural test e5 pad-vdd pad-vdd e5 pad-vdd pad-vdd table 22-3 160 mapbga pin assignments pin bga name typ e description 22-12 mcf5249um motorola pin assignment figure 22-1 144 qfp package (1 of 3) pin assignment motorola section 22 mechanical data 22-13 figure 22-2 144 qfp package (2 of 3) 22-14 mcf5249um motorola pin assignment figure 22-3 144 qfp package (3 of 3) pin assignment motorola section 22 mechanical data 22-15 figure 22-4 160 bga mechanical package (1 of 2) 22-16 mcf5249um motorola pin assignment figure 22-5 160 bga mechanical package (2 of 2) motorola appendix a register memory map a-1 appendix a register memory map table a-1 summarizes the address, name, and byte assignment for registers within the mcf5249. table a-1 cpu memory map address name size (bytes) description cpu + $002 cacr 4 cache control register cpu + $004 acr0 4 access control reg 0 cpu + $005 acr1 4 access control reg 1 cpu + $801 vbr 4 vector base address reg cpu + $c04 rambar0 4 sram 0 configuration register cpu + $c05 rambar1 4 sram 1 configuration register cpu + $c0f mbar 4 module base address register1 cpu + $c0e mbar2 4 module base address register 2 table a-2 mbar address space memory map address byte 0 byte 1 byte 2 byte 3 description mbar + 000h rsr sypcr swivr swsr system control reg mbar2 + 008h pll control reg mbar + 00ch mpark bus master control reg mbar + 040h ipr interrupt pending reg mbar + 044h imr interrupt mask register mbar + 04ch icr0 icr1 icr2 icr3 interrupt control reg mbar + 050h icr4 icr5 icr6 icr7 interrupt control reg mbar + 054h icr8 icr9 icr10 icr11 interrupt control reg mbar + 080h csar0 chip select address reg 0 mbar + 084h csmr0 chip select mask reg 0 mbar + 088h cscr0 chip select control reg 0 mbar + 08ch csar1 chip select address reg 1 mbar + 090h csmr1 chip select mask reg 1 mbar + 094h cscr1 chip select control reg 1 mbar + 098h csar2 chip select address reg 2 mbar + 09ch csmr2 chip select mask reg 2 mbar + 0a0h cscr2 chip select control reg 2 mbar + 0a4h csar3 chip select address reg 3 mbar + 0a8h csmr3 chip select mask reg 3 mbar + 0ach cscr3 chip select control reg 3 a-2 mcf5249um motorola mbar address space memory map mbar + 100h dcr dramc control register mbar + 108h dacr0 dramc addr and control 0 mbar + 10ch dmr0 dramc mask reg 0 mbar + 110h dacr1 dramc addr and control1 mbar + 114h dmr1 dramc mask reg 1 mbar + 140h tmr0 timer mode reg 0 mbar + 144h trr0 timer reference reg 0 mbar + 148h tcr0 timer capture reg 0 mbar + 14c tcn0 timer counter 0 mbar + 150h ter0 timer event reg 0 mbar + 180h tmr1 timer mode reg 1 mbar + 184h trr1 timer reference reg 1 mbar + 188h tcr1 timer counter 1 mbar + 18ch tcn1 mbar + 190h ter1 timer event reg 1 mbar + 1c0h umr10/umr20 uart mode reg 0 mbar + 1c4h usr0/ucsr0 uart status 0 uart clock select reg 10 mbar + 1c8h ucr0 uart command reg 0 mbar + 1cch urb0/utb0 uart receive 0 uart transmit buffer 0 mbar + 1d0h uipcr0/uacr0 uart change 0 uart aux control reg 0 mbar + 1d4h uisr0/uimr0 uart interrupt status 0 uart interrupt mask reg 0 mbar + 1d8h ubg10 uart baud rate generator msb mbar + 1dch ubg20 uart baud rate generator lsb mbar + 1f0 uivr0 uart interrupt vector reg 0 mbar + 1f4h uip0 uart interrupt port 0 mbar + 1f8h uop10 uart rts output port 0 mbar + 1fch uop00 uart output port 0 mbar + 200h umr11/umr21 uart mode reg 1 mbar + 204h usr1/ucsr1 uart status 1 uart clock select reg 1 mbar + 208h ucr1 uart command reg 1 mbar + 20ch urb1/utb1 uart receive 1 uart transmit buffer 1 mbar + 210h uipcr1/uacr1 uart change 1 uart aux control reg 1 mbar + 214h uisr1/uimr1 uart interrupt status 1 uart interrupt mask reg 1 mbar + 218h ubg11 uart baud rate generator msb table a-2 mbar address space memory map address byte 0 byte 1 byte 2 byte 3 description mbar address space memory map motorola appendix a register memory map a-3 mbar + 21ch ubg21 uart baud rate generator lsb mbar + 230 uivr1 uart interrupt vector reg 1 mbar + 234h uip1 uart interrupt port 1 mbar + 238h uop11 uart rts output port 1 mbar + 23ch uop01 uart output port 1 mbar + 280h madr mbus address reg mbar + 284h mfdr mbus frequency reg mbar + 288h mbcr mbus control reg mbar + 28ch mbsr mbus status reg mbar + 290h mbdr mbus data reg mbar + 300h sar0 dma source address reg 0 mbar + 304h dar0 dma destination addr reg 0 mbar + 308h dcr0 dma control reg 0 mbar + 30ch bcr0 dma byte count reg 0 mbar + 310h dsr0 dma status reg 0 mbar + 314h divr0 dma vector reg 0 mbar + 340h sar1 dma source address reg 1 mbar + 344h dar1 dma destination addr reg 1 mbar + 348h dcr1 dma control reg 1 mbar + 34ch bcr1 dma byte count reg 1 mbar + 350h dsr1 dma status reg 1 mbar + 354h divr1 dma vector reg 1 mbar + 380h sar2 dma source address reg 2 mbar + 384h dar2 dma destination addr reg 2 mbar + 388h dcr2 dma control reg 2 mbar + 38ch bcr2 dma byte count reg 2 mbar + 390h dsr2 dma status reg 2 mbar + 394h divr2 dma vector reg 2 mbar + 3c0h sar3 dma source address reg 3 mbar + 3c4h dar3 dma destination addr reg 3 mbar + 3c8h dcr3 dma control reg 3 mbar + 3cch bcr3 dma byte count reg 3 mbar + 3d0h dsr3 dma status reg 3 mbar + 3d4h divr3 dma vector reg 3 mbar + 400 qir qspi mode register mbar + 404 qspiqdlyr qspi delay register mbar + 408 qspiqwr qspi wrap register mbar + 40c qspiqir qspi interrupt register mbar + 410 qspiqar qspi address register table a-2 mbar address space memory map address byte 0 byte 1 byte 2 byte 3 description a-4 mcf5249um motorola audio interface memory map mbar + 414 qir qspi data register unlisted in range mbar + 000 - 04ffh reserved, unpredictable don?t use table a-3 audio interface memory map address access size bits name description mbar2 + 0 r 32 gpio-read shows values of gpio 0-31 inputs mbar2 + 4 rw 32 gpio-out values for gpio 0-31 outputs written to this register mbar2 + 8 rw 32 gpio-enable output enable register for gpios 0-31 mbar2 + c rw 32 gpio-function function selector for multi-purpose gpio 0-31 pins mbar2 + 10 rw 32 iis1config config register for iis interface 1 mbar2 + 14 rw 32 iis2config config register for iis interface 2 mbar2 + 18 rw 32 iis3config config register for iis interface 3 mbar2 + 1c rw 32 iis4config config register for iis interface 4 mbar2 + 20 rw 32 ebu1config config register for ebu interface mbar2 + 24 r 32 ebu1rcvcchannel1 control channel as received by ebu1 interface - first 32 bits mbar2 + 28 rw 32 ebutxcchannel1 ?c? channel bits for ebu transmitter - consumer format mbar2 + 2c rw 32 ebutxcchannel2 ?c? channel bits for ebu transmitter - professional format mbar2 + 30 rw 32 dataincontrol pdir source select mbar2 + 34 mbar2 + 38 mbar2 + 3c mbar2 + 40 r 32 pdir1-l processor data in - left multiple read addresses allow movem instruction to read fifo mbar2 + 44 mbar2 + 48 mbar2 + 4c mbar2 + 50 r 32 pdir3-l processor data in - left multiple read addresses allow movem instruction to read fifo mbar2 + 54 mbar2 + 58 mbar2 + 5c mbar2 + 60 r 32 pdir1-r processor data in - right mbar2 + 64 mbar2 + 68 mbar2 + 6c mbar2 + 70 r 32 pdir3-r processor data in - right table a-2 mbar address space memory map address byte 0 byte 1 byte 2 byte 3 description audio interface memory map motorola appendix a register memory map a-5 mbar2 + 34 mbar2 + 38 mbar2 + 3c mbar2 + 40 w 32 pdor1-l processor data out 1 - left mbar2 + 44 mbar2 + 48 mbar2 + 4c mbar2 + 50 w 32 pdor1-r processor data out 1 - right mbar2 + 54 mbar2 + 58 mbar2 + 5c mbar2 + 60 w 32 pdor2-l processor data out 2 - left mbar2 + 64 mbar2 + 68 mbar2 + 6c mbar2 + 70 w 32 pdor2-r processor data out 2 - right mbar2 + 74 mbar2 + 78 mbar2 + 7c mbar2 + 80 w 32 pdor3 processor data out 3 left + right mbar2 + 74 mbar2 + 78 mbar2 + 7c mbar2 + 80 r 32 pdir2 processor data in 2 left + right mbar2 + 84 rw 32 uchanneltransmit u channel transmit register mbar2 + 88 r 32 u1channelreceive u channel receive register, first ebu receiver mbar2 + 8c r 32 q1channelreceive q channel receive register, first ebu receiver mbar2 + 92 rw 8 cd text control cd text configuration register mbar2 + 94 rw 32 interrupten interrupt enable register mbar2 + 98 w 32 interruptclear clear interrupt register mbar2 + 98 r 32 interruptstat interrupt status register mbar2 + 9f rw 8 dmaconfig configure dma mbar2 + a3 rw 8 phaseconfig configure phase measurement circuit mbar2 + a6 rw 16 xtrim value output on xtrim pin mbar2 + a8 r 32 freqmeas phase /frequency measurement mbar2 + af rw 8 reserved reserved mbar2 + ca rw 16 blockcontrol block decoder / encoder control mbar2 + ce rw 16 audioglob audio block new features mbar2 + d0 rw 32 ebu2config config register for ebu2 interface mbar2 + d4 r 32 ebu2rcvcchannel1 control channel as received by ebu2 interface - first 32 bits table a-3 audio interface memory map address access size bits name description a-6 mcf5249um motorola gpio and interrupt status memory map mbar2 + d8 r 32 u2channelreceive u channel receive register, second ebu receiver mbar2 + dc r 32 q2channelreceive q channel receive register, second ebu receiver table a-4 gpio and interrupt status memory map address access size bits name description mbar2 + b0 r 32 gpio1-read shows values of gpio 32-63 inputs mbar2 + b4 rw 32 gpio1-out values for gpio 32-63 outputs written to this register mbar2 + b8 rw 32 gpio1-enable output enable register for gpio 32-63 mbar2 + bc rw 32 gpio1-function function selector for multi-purpose gpio 62-63 pins mbar2 + c0 r 32 gpio-int-stat interrupt status 2 mbar2 + c0 w 32 gpio-int-clear interrupt clear 2 mbar2 + c4 rw 32 gpio-int-en interrupt enable 2 mbar2 + e0 r 32 interruptstat3 interrupt status 3 mbar2 + e0 w 32 interruptclear3 interrupt clear 3 mbar2 + e4 rw 32 interrupten3 interrupt enable 3 mbar2 + 140 rw 32 intpri1 interrupts 0-7 level mbar2 + 144 rw 32 intpri2 interrupts 8-15 level mbar2 + 148 rw 32 intpri3 interrupts 16-23 level mbar2 + 14c rw 32 intpri4 interrupts 24-31 level mbar2 + 150 rw 32 intpri5 interrupts 32-39 level mbar2 + 154 rw 32 intpri6 interrupts 40-47 level mbar2 + 158 rw 32 intpri7 interrupts 48-55 level mbar2 + 15c rw 32 intpri8 interrupts 56-63 level mbar2 + 167 rw 8 spurvec spurious interrupt vector number mbar2 + 16b rw 8 intbase interrupt base vector register mbar2 + 180 rw 32 pllcontrol register to program pll frequency mbar2 + 188 rw 32 dmaroute dma source control mbar2 + 18c rw 32 ide config1 ide interface configuration register mbar2 + 190 rw 32 ide config2 ide interface configuration register mbar2 + 194 r 32 iperroradr address of last error on ipbus mbar2 + 198 rw 32 extraint interrupt monitors and software interrupts mbar2 + 200 rw 32 qspi interface? table a-3 audio interface memory map address access size bits name description a/d, mbus2 and memory stick memory map motorola appendix a register memory map a-7 table a-5 a/d, mbus2 and memory stick memory map address access size bits name description mbar2 + 402h rw 16 adconfig ad configuration and status register mbar2 + 406h r 16 advalue ad measurement result mbar2 + 408h - 43ch reserved, unpredictable don?t use mbar2 + 440h rw 8 madr2 m-bus 2 address register mbar2 + 444h rw 8 mfdr2 m-bus 2 frequency divider register mbar2 + 448h rw 8 mbcr2 m-bus 2 control register mbar2 + 44ch rw 8 mbsr m-bus 2 status register mbar2 + 450h rw 8 mbdr m-bus 2 data i/o register mbar2 + 460h rw 32 flashmediaconfig clock and general configuration mbar2 + 464h rw 32 flashmediacmd1 command register for interface 1 mbar2 + 468h rw 32 flashmediacmd2 command register for interface 2 mbar2 + 46ch rw 32 flashmediadata1 data register for interface 1 mbar2 + 470h rw 32 flashmediadata2 data register for interface 2 mbar2 + 474h rw 32 flashmediastatus status register mbar2 + 478h rw 32 flashmediainten interrupt enable register mbar2 + 47ch r 32 flashmediaintstat interrupt status register mbar2 + 47ch w 32 flashmediaintclear interrupt clear register mcf5249um/d how to reach us: usa/europe/locations not listed: motorola literature distribution p.o. box 5405, denver, colorado 80217 1-303-675-2140 or 1-800-441-2447 japan: motorola japan ltd. sps, technical information center 3-20-1, minami-azabu minato-ku tokyo 106-8573 japan 81-3-3440-3569 asia/pacific: motorola semiconductors h.k. ltd. silicon harbour centre, 2 dai king street tai po industrial estate, tai po, n.t., hong kong 852-26668334 technical information center: 1-800-521-6274 home page: www.motorola.com/semiconductors document comments: fax: 1-512-933-2625 attn: risc applications engineering information in this document is provided solely to enable system and software implementers to use motorola products. there are no express or implied copyright licenses granted hereunder to design or fabricate any integrated circuits or integrated circuits based on the information in this document. motorola reserves the right to make changes without further notice to any products herein. motorola makes no warranty, representation or guarantee regarding the suitability of its products for any particular purpose, nor does motorola assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages. typical parameters which may be provided in motorola data sheets and/or specifications can and do vary in different applications and actual performance may vary over time. all operating parameters, including typicals must be validated for each customer application by customers technical experts. motorola does not convey any license under its patent rights nor the rights of others. motorola products are not designed, intended, or authorized for use as components in systems intended for surgical implant into the body, or other applications intended to support or sustain life, or for any other application in which the failure of the motorola product could create a situation where personal injury or death may occur. should buyer purchase or use motorola products for any such unintended or unauthorized application, buyer shall indemnify and hold motorola and its officers, employees, subsidiaries, affiliates, and distributors harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of personal injury or death associated with such unintended or unauthorized use, even if such claim alleges that motorola was negligent regarding the design or manufacture of the part. motorola and the stylized m logo are registered in the u.s. patent and trademark office. digital dna is a trademark of motorola, inc. all other product or service names are the property of their respective owners. motorola, inc. is an equal opportunity/affirmative action employer. ? motorola, inc. 2002 |
Price & Availability of MCF5249LPV120
 |
|
|
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
| [Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
|
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |